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

From: Dave Rochwerger <[email-masked]>
Date: Wed, 7 Sep 2011 14:15:59 -0700

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

---

From: William Mills <[email-masked]>
Date: Wed, 7 Sep 2011 15:27:34 -0700 (PDT)

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 <[email-masked]>
To: [email-masked]
Cc: Quizlet Dev Team <[email-masked]>
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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 7 Sep 2011 16:24:11 -0700

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 <[email-masked]> wrote:

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Sep 2011 16:23:51 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hunt
Sent: Wednesday, September 07, 2011 4:24 PM
To: William Mills
Cc: Quizlet Dev Team; [email-masked]
Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)

Phil

On 2011-09-07, at 15:27, William Mills <[email-masked]<mailto:[email-masked]>> 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.

-bill

________________________________
From: Dave Rochwerger <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Cc: Quizlet Dev Team <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 7, 2011 2:15 PM
Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Hi all,

Our scenario:
==========

Our architecture:
============

Questions:
========

Regards,
Dave

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 7 Sep 2011 17:07:43 -0700

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 <[email-masked]> 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
>
> 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 <[email-masked]>
> *To:* <[email-masked]>[email-masked]
> *Cc:* Quizlet Dev Team <[email-masked]>
> *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
> - The only verification then, is to enforce redirect URI registration and
> to validate the redirect URI between authorization and token steps.
>
> 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
>
>
> <[email-masked]>[email-masked]
> <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 7 Sep 2011 17:08:25 -0700

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 <[email-masked]>wrote:

> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Phillip Hunt
> *Sent:* Wednesday, September 07, 2011 4:24 PM
> *To:* William Mills
> *Cc:* Quizlet Dev Team; [email-masked]
> *Subject:* Re: [OAUTH-WG] OAuth2 Implementation questions (client secret
> and refresh tokens)****
>
> ** **
>
> (without the user) before getting a new access token. ****
>
> ** **
>
> ****
> Phil****
> On 2011-09-07, at 15:27, William Mills <[email-masked]> wrote:****
>
> MAC for example.****
> ** **
> something new with the access tokens.****
>
> ** **
>
> -bill****
>
> ** **
> *To:* [email-masked]
> refresh tokens)****
> Hi all,****
> ** **
> fundamental questions that I am unable to defend.****
>
> ** **
>
> I am hoping this group could help answer them for me.****
>
> ** **
>
> Our scenario:****
>
> ==========
> applications are not a concern at the moment).****
>
> * We want to provide very long-lived (forever) tokens.****
>
> to re-authorize every hour).****
>
> ** **
>
> Our architecture:****
>
> ============****
>
> * We control both the API server and the authorization server.****
>
> done over SSL.****
> always done over SSL.****
>
> guidelines say they must verify the state for CSRF mitigation).****
>
> * We enforce that every client must register a redirect URI.****
>
> that was used to obtain the auth code.****
>
> redirect URI.****
> 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?****
>
> in the archives) are not an issue.****
>
> id, secret and refresh token.****
>
> often) and seems to provide no benefit for our case.****
>
> ** **
>
> ** **
>
> 2. What is the point of the client secret (in our scenario)? ****
>
> them as public (phone apps can be decompiled and the secret discovered).**
> **
>
> send their public client id (and no secret).****
>
> to validate the redirect URI between authorization and token steps.****
>
> ** **
>
> as public and not worry about a secret?****
>
> ****
> ** **
> ** **
> be seen here: https://github.com/quizlet/oauth2-php****
>
> ** **
>
> Regards,****
>
> Dave****
>
>
>
> ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 7 Sep 2011 17:08:56 -0700

See below...
Phil

@independentid
www.independentid.com
[email-masked]

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. 

The user does not have to be present.  
> 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.

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 7 Sep 2011 17:05:19 -0700

Dave.

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 7 Sep 2011 17:22:14 -0700

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 <[email-masked]> wrote:

> 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.
>
>> 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
>>
>> * 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).
>> browser (and not an embedded web UI).
>>
>> Questions:
>> ========
>>   - 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%

---

From: Phil Hunt <[email-masked]>
Date: Wed, 7 Sep 2011 17:54:27 -0700

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
[email-masked]

On 2011-09-07, at 5:22 PM, Dave Rochwerger wrote:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Sep 2011 16:20:38 +0200

Hi Dave,

On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:

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

> 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] [email-masked] [12]
>>
>>> Hi Phil, >> The client is then forced to periodically 
>>> reauthenticate
>>>>> 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.
>> 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:
>>>>
>>>>> 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: [email-masked] [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.
>>>>> * 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 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 enforce that every client must supply the state parameter
>>>>> (and our guidelines say they must verify the state for CSRF
>>>>> mitigation).
>>>>> * 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:
>>>>> ========
>>>>> - 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?
>>>>> Our API source is not available, but the oauth2 server
>>>>> implementation can be seen here:
>>>>> https://github.com/quizlet/oauth2-php [4]
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>> [email-masked] [5]
>>>>> https://www.ietf.org/mailman/listinfo/oauth [6]
>>>>
>>>>> [email-masked] [7]
>>>>> https://www.ietf.org/mailman/listinfo/oauth [8]

Links:
------
[1] mailto:[email-masked]
[2] mailto:[email-masked]
[3] mailto:[email-masked]
[4] https://github.com/quizlet/oauth2-php
[5] mailto:[email-masked]
[6] https://www.ietf.org/mailman/listinfo/oauth
[7] mailto:[email-masked]
[8] https://www.ietf.org/mailman/listinfo/oauth
[9] mailto:[email-masked]
[10] mailto:[email-masked]
[11] http://www.independentid.com
[12] mailto:[email-masked]
[13] mailto:[email-masked]

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 14 Sep 2011 10:12:52 -0700

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
<[email-masked]> wrote:
>> 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.
> 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.
>
>
>> 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
>> That all sounds good, but in our situation (all SSL, etc) - what do we
> 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.
>
>>
>>>> Hi Phil, >> The client is then forced to periodically reauthenticate
>>>> Hence it is better to use shorter lived access tokens with long lived
>>>> refresh tokens.
>>> revocation. But, by having a short expiration time on the access token
>>> rotation and authorization re-verification without having to re-involve
>>> the end-user.
>>>
>>> Dave.>
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Sep 2011 21:51:57 +0200

Hi Dave,

redirect URI validation does not authenticate a client. For example, a 
URI registered for a private web client could be used by a (malicious) 
native app to assume the web app's identity. The client secret, in 
contrast, can be used to authenticate it.

regards,
Torsten.

Am 14.09.2011 19:12, schrieb Dave Rochwerger:
>>>>> Hi Phil,>>  The client is then forced to periodically reauthenticate

---

From: Dave Rochwerger <[email-masked]>
Date: Wed, 14 Sep 2011 13:45:42 -0700

Is this a security issue in the OAuth2 process then (for mobile apps using
the authorization code flow)?

1. The draft says that mobile apps should be considered public clients
because mobile apps can be decompiled and can not keep their credentials
private.
2. In this case then, the draft says for these mobile apps to not
authenticate with the secret and instead for the server to verify the
redirect URI (and make it mandatory).
3. You said that verifying the redirect URI is not good enough to verify the
client's identity.

What am I missing?

Thanks,
Dave

On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi Dave,
>
> redirect URI validation does not authenticate a client. For example, a URI
> registered for a private web client could be used by a (malicious) native
> app to assume the web app's identity. The client secret, in contrast, can be
> used to authenticate it.
>
> regards,
> Torsten.
>
>>> 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.
>>>
>>>
>>> http://tools.ietf.org/html/**draft-lodderstedt-oauth-**
>>> security-01#section-4.1.2<http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2>
>>> ).
>>>
>>> regards,
>>> Torsten.
>>>
>>>>>>>> https://github.com/quizlet/**oauth2-php<https://github.com/quizlet/oauth2-php>[4]
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Dave
>>>>>>>>
>>>>>>>> ______________________________**_________________
>>>>>>>> OAuth mailing list
>>>>>>>> [email-masked] [5]
>>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>[6]
>>>>>>>>
>>>>>>>
>>>>>>>  ______________________________**_________________
>>>>>>>> OAuth mailing list
>>>>>>>> [email-masked] [7]
>>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>[8]
>>>>>>>>
>>>>>>>
>>>
>>>
>>> Links:
>>> ------
>>> [4] https://github.com/quizlet/**oauth2-php<https://github.com/quizlet/oauth2-php>
>>> [6] https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>> [8] https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>> ______________________________**_________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 16 Sep 2011 21:01:26 +0200

Hi Dave,

there has been a long debate about native client security and you can 
also find a comprehensive analysis in the security document.

It's just a fact that such clients cannot reliably be authenticated in a 
public environment (even if malicious clients can be detected in some 
cases). So it is the responsibility of the resource owner to validate 
the authenticity/trustworthiness of an app before using it. The authz 
server's task is to authz access to cloud resources, so it asks the 
resource owner for consent. Once the consent is given, the refresh token 
itself represents the fact that the holder should be a legitimate client.

regards,
Torsten.
------------------------------------------------------------------------
*From: * Dave Rochwerger <[email-masked]>
*Date: *Wed, 14 Sep 2011 13:45:42 -0700
*To: *Torsten Lodderstedt<[email-masked]>
*Cc: *<[email-masked]>
*Subject: *Re: [OAUTH-WG] OAuth2 Implementation questions (client secret 
and refresh tokens)

Is this a security issue in the OAuth2 process then (for mobile apps 
using the authorization code flow)?

3. You said that verifying the redirect URI is not good enough to verify 
the client's identity.

What am I missing?

Thanks,
Dave

On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt 
<[email-masked] <mailto:[email-masked]>> wrote:

    Hi Dave,

    redirect URI validation does not authenticate a client. For example,
    a URI registered for a private web client could be used by a
    (malicious) native app to assume the web app's identity. The client
    secret, in contrast, can be used to authenticate it.

    regards,
    Torsten.

        Thanks,
        Dave

        On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
        <[email-masked] <mailto:[email-masked]>>  wrote:

            Hi Dave,

                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.

                    See below...

                    Phil
                    @independentid
                    www.independentid.com <http://www.independentid.com>
                    [11] [email-masked]
                    <mailto:[email-masked]> [12]

                        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.

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

                            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

                                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: [email-masked]
                                <mailto:[email-masked]> [2]
                                CC: Quizlet Dev Team
                                SENT: Wednesday, September 7, 2011 2:15 PM
                                SUBJECT: [OAUTH-WG] OAuth2
                                Implementation questions (client

                                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 [4]

                                Regards,
                                Dave

                                _______________________________________________
                                OAuth mailing list
                                [email-masked] <mailto:[email-masked]> [5]
                                https://www.ietf.org/mailman/listinfo/oauth
                                [6]

                                _______________________________________________
                                OAuth mailing list
                                [email-masked] <mailto:[email-masked]> [7]
                                https://www.ietf.org/mailman/listinfo/oauth
                                [8]

            Links:
            ------
            [1] mailto:[email-masked] <mailto:[email-masked]>
            [2] mailto:[email-masked] <mailto:[email-masked]>
            [3] mailto:[email-masked] <mailto:[email-masked]>
            [4] https://github.com/quizlet/oauth2-php
            [5] mailto:[email-masked] <mailto:[email-masked]>
            [6] https://www.ietf.org/mailman/listinfo/oauth
            [7] mailto:[email-masked] <mailto:[email-masked]>
            [8] https://www.ietf.org/mailman/listinfo/oauth
            [9] mailto:[email-masked] <mailto:[email-masked]>
            [10] mailto:[email-masked] <mailto:[email-masked]>
            [11] http://www.independentid.com
            [12] mailto:[email-masked] <mailto:[email-masked]>
            [13] mailto:[email-masked] <mailto:[email-masked]>

            _______________________________________________
            OAuth mailing list
            [email-masked] <mailto:[email-masked]>
            https://www.ietf.org/mailman/listinfo/oauth