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 >> 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
