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 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
