OAuth2 - unnecessary complexity with refresh token

问题:

I do not clearly understand, why there is a refresh/access token concept in oauth2 if the endpoint is the same (authorization) server as depicted many times in RFC6749.

The first authorization step when the resource owner authorizes any third party component without sharing credentials, is the essential idea of oauth2. Using an authorization token to generate an access and refresh token is only another level of authorization indirection imho, but no increase in security.

Since the authorization server is the same, the access token is as sensitive as the authorization token and refresh token, thus I would call it unnecessary complexity.

The only explanation making sense for me is, if someone stole the access token the client is able to request a new access token. But how did someone steel it? If it is a man in the middle, then he also has the refresh token, when client requests a new one.

My question is: why does the authorization server not just return an access token which can be revoked by client and resource owner? What is the benefit of refresh/access token strategy?

Thank you for your explanations.

回答1:

The refresh token is an attempt to resolve fine-grain access checks with the server load. Reducing server load occurs when a resource owner caches the access token between calls so that it can authorize subsequent calls without going to the authorization server. This dramatically reduces load on the authz server. But this introduces a problem in that changes in the token's permissions, specifically reductions in what the token can be used for, are never seen by the resource owner as it's caching the access token.

Now a well-behaved resource owner would know that it should only hold cache the token for a short while before reconfirming it with the authorization server. But you can't rely on resource owners being well behaved. So, the authorization server puts a relatively short expiration on the access token. This forces the client to use the refresh token to get a new access token. Then the resource owner will validate the new access token and get the current rights for the token.

It is important to note that refreshing the access token happens without user interaction. If reauthentication was not a problem for the user interaction model, the refresh token wouldn't be needed and the user could just reauthenticate. But that would kind of suck.

This means that if the user were to remove permissions from their OAuth account, resource owners will continue to function with the old permission set until the access token expires. The new access token will then be obtained and the new permission set will take effect.

回答2:

In addition to Neil's great answer: in the case that there is only a single token how do you imagine that revoking that token will happen? This necessarily would involve the Resource Server (RS) consulting the Authorization Server (AS) which is a huge overhead. That is exactly why the split exists: the short-lived access token can live on it's own independently of checks at the AS. The long-lived refresh token reconciles access rights with the AS.