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<[email protected]>
To: OAuth WG<[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
