The main source of confusion about refresh token is caused by the protocol lack of clear definition of access token lifetime, even in relative terms, and the objectives of refresh tokens. For example, the authorization server can issue:
- an access token good for an hour, with a refresh token good for a year or good-till-revoked - an access token good-till-revoked without a refresh token - an access token good-till-revoked with a refresh token, used to obtain additional access tokens for a distributed environment In large scale systems access tokens are often self-describing, including all the information needed by the resource server to validate them. In such a setup, access tokens cannot be revoked until expired. Refresh tokens on the other hand, require a database lookup for the resource owner grant, and can be revoked. The only real difference between the implicit and authorization code grant types is the inclusion of a refresh token. The point is not to issue long term credentials without client authentication, relying on the presence of the resource owner for authenticating the client. However, we don't say that anywhere, or define the goals of the two token types design with enough detail to offer sound security. I would like to add a quick discussion of access token and refresh token recommended deployment setup, providing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the access token. It's time we stop trying to accommodate every possible combination and make some hard choices. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
