Re: [OAUTH-WG] Multiple access tokens

Am 09.03.2012 00:15, schrieb Ross Boucher:
> 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.

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.

>
> (Also, worth noting that I wasn't talking about user revocation, which definitely should revoke the refresh token).
>
> On Mar 7, 2012, at 11:12 PM, William Mills wrote:
>
>> 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<rboucher@gmail.com>
>> To: OAuth WG<oauth@ietf.org>
>> Cc:
>> Sent: Wednesday, March 7, 2012 6:14 PM
>> Subject: [OAUTH-WG] Multiple access tokens
>>
>> 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
>> _______________________________________________
>> 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