Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.h...@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill - FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Thanks for the follow up, Torsten. Whilst I have your attention - any thoughts on my second question, about the use of a client secret? If for all clients we mandated registered URIs and verified them (whether they are private and public), what additional security does the client secret actually provide for private clients in the authorization code flow? Thanks, Dave On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.h...@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill - FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill - FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification then, is to enforce redirect URI registration and to validate the redirect URI between authorization and token steps. So, the question is, assuming that we, one: enforce redirect-URI registration and two: validate that URI - why can't we treat all clients as public and not worry about a secret? What is the benefit of having confidential clients (and a secret) at all? Our API source is not available, but the oauth2 server implementation can be seen here: https://github.com/quizlet/**oauth2-phphttps://github.com/quizlet/oauth2-php[4] Regards, Dave __**_ OAuth mailing list OAuth@ietf.org [5] https://www.ietf.org/mailman/**listinfo/oauthhttps://www.ietf.org/mailman/listinfo/oauth[6] __**_ OAuth mailing list OAuth@ietf.org [7] https://www.ietf.org/mailman/**listinfo/oauthhttps
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill From: Dave Rochwerger da...@quizlet.com To: oauth@ietf.org Cc: Quizlet Dev Team devt...@quizlet.com Sent: Wednesday, September 7, 2011 2:15 PM Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification then, is to enforce redirect URI registration and to validate the redirect URI between authorization and token steps. So, the question is, assuming that we, one: enforce redirect-URI registration and two: validate that URI - why can't we treat all clients as public and not worry about a secret? What is the benefit of having confidential clients (and a secret) at all? Our API source is not available, but the oauth2 server implementation can be seen here: https://github.com/quizlet/oauth2-php Regards, Dave ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill From: Dave Rochwerger da...@quizlet.com To: oauth@ietf.org Cc: Quizlet Dev Team devt...@quizlet.com Sent: Wednesday, September 7, 2011 2:15 PM Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification then, is to enforce redirect URI registration and to validate the redirect URI between authorization and token steps. So, the question is, assuming that we, one: enforce redirect-URI registration and two: validate that URI - why can't we treat all clients as public and not worry about a secret? What is the benefit of having confidential clients (and a secret) at all? Our API source is not available, but the oauth2 server implementation can be seen
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
You can revoke access tokens but only if they are Stateful (which usually means a DB lookup for every API call which doesn’t scale as well). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phillip Hunt Sent: Wednesday, September 07, 2011 4:24 PM To: William Mills Cc: Quizlet Dev Team; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill From: Dave Rochwerger da...@quizlet.commailto:da...@quizlet.com To: oauth@ietf.orgmailto:oauth@ietf.org Cc: Quizlet Dev Team devt...@quizlet.commailto:devt...@quizlet.com Sent: Wednesday, September 7, 2011 2:15 PM Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt phil.h...@oracle.com wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill -- *From:* Dave Rochwerger da...@quizlet.com *To:* oauth@ietf.orgoauth@ietf.org *Cc:* Quizlet Dev Team devt...@quizlet.com *Sent:* Wednesday, September 7, 2011 2:15 PM *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
All our access tokens are currently stateless. All API calls are going to have to make DB/memcache calls to do anything interesting anyway, one extra call to check the access token shouldn't have a drastic effect. At the very least, we need to lookup/confirm the user exists, so we are going to make at least a couple of DB/memcache calls on every API request anyway. We do use caching, so we could potentially cache access tokens just like other data we use. As a (slight) aside, I did have the thought of keeping only refresh tokens in the DB and using a non-persistant caching layer like memcache to hold short-lived access tokens (so, in the event of loosing the cache, clients simply need to refresh and get new access tokens). But even the benefit of this did not outweigh the cost of the extra complication for 3rd party developers to have to implement the extra work of handling refresh tokens and the refresh process. Dave. On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: You can revoke access tokens but only if they are Stateful (which usually means a DB lookup for every API call which doesn’t scale as well). ** ** EHL ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Phillip Hunt *Sent:* Wednesday, September 07, 2011 4:24 PM *To:* William Mills *Cc:* Quizlet Dev Team; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) ** ** You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. ** ** Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. ** ** If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. ** ** -bill ** ** -- *From:* Dave Rochwerger da...@quizlet.com *To:* oauth@ietf.org *Cc:* Quizlet Dev Team devt...@quizlet.com *Sent:* Wednesday, September 7, 2011 2:15 PM *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, ** ** I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. ** ** I am hoping this group could help answer them for me. ** ** Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). ** ** Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). ** ** Questions: 1. Given the above scenario
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
All our access tokens are currently stateless. All API calls are going to have to make DB/memcache calls to do anything interesting anyway, one extra call to check the access token shouldn't have a drastic effect. At the very least, we need to lookup/confirm the user exists, so we are going to make at least a couple of DB/memcache calls on every API request anyway. We do use caching, so we could potentially cache access tokens just like other data we use. As a (slight) aside, I did have the thought of keeping only refresh tokens in the DB and using a non-persistant caching layer like memcache to hold short-lived access tokens (so, in the event of loosing the cache, clients simply need to refresh and get new access tokens). But even the benefit of this did not outweigh the cost of the extra complication for 3rd party developers to have to implement the extra work of handling refresh tokens and the refresh process. Dave. On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: You can revoke access tokens but only if they are Stateful (which usually means a DB lookup for every API call which doesn’t scale as well). ** ** EHL ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Phillip Hunt *Sent:* Wednesday, September 07, 2011 4:24 PM *To:* William Mills *Cc:* Quizlet Dev Team; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) ** ** You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. ** ** Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. ** ** If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. ** ** -bill ** ** -- *From:* Dave Rochwerger da...@quizlet.com *To:* oauth@ietf.org *Cc:* Quizlet Dev Team devt...@quizlet.com *Sent:* Wednesday, September 7, 2011 2:15 PM *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, ** ** I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. ** ** I am hoping this group could help answer them for me. ** ** Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). ** ** Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). ** ** Questions: 1. Given the above scenario
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt phil.h...@oracle.com wrote: See below... Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt phil.h...@oracle.com wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill -- *From:* Dave Rochwerger da...@quizlet.com *To:* oauth@ietf.orgoauth@ietf.org *Cc:* Quizlet Dev Team devt...@quizlet.com *Sent:* Wednesday, September 7, 2011 2:15 PM *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
I agree, it is a matter of tradeoffs, but I think you have the idea. As for your question in 3, think of rotation as following the same practice as periodic re-authentication of browser based users. If you never do that, you probably don't care to re-authenticate client apps either. But if you do it hourly, you probably want your access tokens to expire hourly too. In that case refresh is useful since it keeps clients from having to go through re-authorization (which usually involves the end-users). One other thought. If you are using bearer tokens, then a compromise of your token db would lead to more exposure than a compromise of refresh tokens. Why? Because refresh tokens require authentication from the client before they can be used. It is just another layer of protection that again may or may not have value for you. Hope that helps! Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-07, at 5:22 PM, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt phil.h...@oracle.com wrote: See below... Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt phil.h...@oracle.com wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill From: Dave Rochwerger da...@quizlet.com To: oauth@ietf.org Cc: Quizlet Dev Team devt...@quizlet.com Sent: Wednesday, September 7, 2011 2:15 PM Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some
