Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)

[Dave Rochwerger <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> *To:* <[e-mail]>[e-mail]
> *Cc:* Quizlet Dev Team <[e-mail]>
> *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>
> https://github.com/quizlet/oauth2-php
>
> Regards,
> Dave
>
>
> _______________________________________________
> OAuth mailing list
> <[e-mail]>[e-mail]
> <https://www.ietf.org/mailman/listinfo/oauth>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>