OAuth2RefreshTokenAuthenticationProvider does not check user or consent

[OrangeDog]

Describe the bug
When a refresh token is used, the authorization server is supposed to revalidate the access. That's the whole point of the refresh token, otherwise it's no different to an access token that just lasts longer.

However, things like revoking consent or disabling the user do not have any effect, and the client can still get a new access token for that user.

To Reproduce
Setup basic sample application including a way to edit the user and consent repositories.
Complete an authorization_code grant to issue an access and refresh token for a user.
Edit the user so that e.g. isEnabled() returns false .
Attempt a refresh_token grant with the previously issued token.

Expected behavior
The status of the user should be checked when using a refresh token. In the above case it should fail.

Similarly, if the client were configured to require consent, and the consent is deleted before refreshing, the refresh attempt should fail.

[OrangeDog]

There is also apparently no way to provide custom validation of this: #1941

[jgrandja]

@OrangeDog

things like revoking consent or disabling the user do not have any effect

These specific validations are not outlined in the spec so it would be custom behaviour that the consuming application would be responsible for.

Furthermore, when a user is disabled or if consent is deleted for a client then it's up to that specific process to revoke any/all tokens, including the refresh token, via the /oauth2/revoke endpoint. And since OAuth2RefreshTokenAuthenticationProvider performs the check if (!refreshToken.isActive()) it would fail. This is the way the flow would work.

There is also apparently no way to provide custom validation of this

At the moment there is no way. When gh-1941 is merged you'll be able to plug in your custom behaviour.

[OrangeDog]

not outlined in the spec

Neither is the consent system you have implemented, but omitted the revalidation for.

revoke any/all tokens, including the refresh token, via the /oauth2/revoke endpoint

That endpoint is for clients to use on behalf of the user, in order to revoke the specific token that it has.

These processes are done by the authorization server, and there's no interface provided (e.g. via OAuth2AuthorizationService) to find/revoke all a users' tokens, nor all tokens that depend on a specific consent.

And there doesn't need to be, because that's part of the problem that refresh tokens were supposed to solve - forcing a revalidation without a user interaction.

When #1941 is merged you'll be able to plug in your custom behaviour.

Is there an ETA for that, and/or do you already know at what line in the provider it would be called?