Refresh tokens cannot reduce scopes correctly

[ThisIsMissEm]

In OAuth 2.0, when using refresh tokens via the refresh_token grant flow, it is possible to reduce the scope of the new access token, and then to restore the access token back to the originally authorized scopes.

From: https://www.rfc-editor.org/rfc/rfc6749#section-6

The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.

What this essentially means is that the refresh token always has the full authorized scopes available, but the access token it generates may have reduced scopes.

So the flow goes as follows:

1. authorization code grant flow is authorized with scopes read write
2. authorization code is exchanged for the first access token and first refresh token.
3. first access token has read write scopes
4. first refresh token used with read (by passing scope parameter when refreshing)
5. second access token is issued and should have read scope, the second refresh token should still have read write scope.
6. second refresh token is used with read write (expanding the scope back to originally authorized scopes)
7. third access token should have read write scope, since it was originally authorized by the access grant.

You can see a rspec request test for this in: main...ThisIsMissEm:doorkeeper:feat/refresh-token-scope-changing

At this time, I think this ability is not supported by doorkeeper, and supporting it would mean having to change how all access tokens and refresh tokens persisted. Instead of the refresh token just being a column on oauth_access_tokens we either need a table oauth_refresh_tokens OR we need to make the oauth_access_tokens table support both access tokens and refresh tokens via a token_type column, and then some sort of relationship between the two would need to be established (I think)

This is also related to #1719 and the whole concept of "token families" basically the access grant specifies the start of the token family, then each access token and refresh token form a somewhat tree structure.

[ThisIsMissEm]

By making the change to separate refresh tokens from access tokens, it would also pave the way for a refresh token to have a configurable expiry, as the person in #1731 expected to be able to do.

It's not uncommon to have access tokens expire in 5-15 minutes, but then have the refresh token valid for 30 days.

[kmayer]

We are feeling a similar pain, too. +1