My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token would limit the time an attacker would have access
revocation: if the access token is self contained, authorization can be revoked by not issuing new access tokens. A resource does not need to query the authorization server to see if the access token is valid.This simplifies access token validation and makes it easier to scale and support multiple authorization servers. There is a window of time when an access token is valid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > Nowhere in the specification is there explanation for refresh tokens, The > reason that the Refresh token was introduced was for anonymity. The scenario > is that a client asks the user for access. The user wants to grant the access > but not tell the client the user's identity. By issuing the refresh token as > an 'identifier' for the user (as well as other context data like the > resource) it's possible now to let the client get access without revealing > anything about the user. Recommend that the above explanation be included so > developers understand why the refresh tokens are there. > _______________________________________________ > 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
