Subject: [OAUTH-WG] Multiple access tokens

From: Ross Boucher <[email-masked]>
Date: Wed, 7 Mar 2012 18:14:34 -0800

The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens?

An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? And, if so, should any tokens issued with that refresh token then also be revoked? It seems simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens.

Thanks,
Ross

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 08 Mar 2012 08:01:02 +0100

Hi,

Ross Boucher <[email-masked]> schrieb:

>The spec doesn't seem to have any recommendations on this point, but
>should an OAuth v2 API always return the same access token if the same
>client makes multiple requests? Is there any benefit to not generating
>a new access token for each request?

I don't see any.

>Similarly, if you do generate new
>access tokens (as I am doing now), should you also generate new refresh
>tokens?

Depends on the grant type. I would expect an authz server to generate new refresh tokens for "code", whether the authz server creates a new one for grant type "refresh_token" might depend on server impl. and client-specific policy (refresh token rotation).

>
>An unrelated question about revoking access tokens when the same
>authorization code is used more than once: should refresh tokens also
>be revoked? 

Does it make sense to not revoke refresh token? Otherwise, it could be used to obtain fresh access tokens.

> And, if so, should any tokens issued with that refresh
>token then also be revoked? It seems

:-) sounds reasonable but not nessessarily feasable

> simpler (if slightly less correct)
>to just revoke all access tokens for that specific client/resource pair
>in that case, rather than tracking the ancestry of all tokens.

Generally, I would consider revoking access tokens more difficult then revoking refresh tokens. It depends on your token design. One can use handles for refresh tokens and self-contained access tokens and revoke refresh tokens only. In that case, I would limit the access token lifetime in order to force a periodic refresh.

Regarding client/resource: 
Depends on whether you are able to really identify a particular client instance. Otherwise, you would revoke tokens for different (potentially a lot of) client installations using the same client_id.

regards,
Torsten.

>
>Thanks,
>Ross_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Wed, 7 Mar 2012 23:12:06 -0800 (PST)

You might want to put issuance time and other info in an access token.  The spec is silent on your first question.

On revocation: One of the reasons for short lived access tokens is to only revoke the refresh token, which has to be presented at a central server type rather than trying to extend revocation to all protected resources.  So if you're in that model you would not bother revoking the access token.

The use case I can see for invalidating access tokens and still honoring refresh tokens is the case where you might have had the access token symmetric secret compromised but not the refresh token secret.  That's not really user revocation though.  I don't se an actual user revocation of access that would not potentially kill both tokens and always kill the refresh token.

----- Original Message -----
From: Ross Boucher <[email-masked]>
To: OAuth WG <[email-masked]>
Cc: 
Sent: Wednesday, March 7, 2012 6:14 PM
Subject: [OAUTH-WG] Multiple access tokens

Thanks,
Ross
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Ross Boucher <[email-masked]>
Date: Thu, 8 Mar 2012 15:15:39 -0800

If the refresh token is revoked, the client application would seem to have no way to gain access to the third party resource again except through another explicit user generated authentication. Is that correct? On some level this may be desirable, since a compromised auth code also implies that whatever out of band authentication method is being used by the client has also been compromised. But then that would be true for all refresh tokens ever issued, rather than just ones stemming from the "poisoned" auth code.

(Also, worth noting that I wasn't talking about user revocation, which definitely should revoke the refresh token).

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Mar 2012 12:52:29 +0100

> If the refresh token is revoked, the client application would seem to have no way to gain access to the third party resource again except through another explicit user generated authentication. Is…

Why? my assumption would be that the attacker gained access to that 
particular authorization code (e.g. by wire tapping). This does not mean 
other refresh tokens for the same or other users have been comprimized 
as well.

regards,
Torsten.

>> From: Ross Boucher<[email-masked]>
>> To: OAuth WG<[email-masked]>
>> Cc: