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
