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). 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
