Refreshed access token is inactive after token revocation

[ufkl]

Describe the bug
After revoking access token, any new access token generated by exchanging refresh token is invalid.

Artifact: spring-security-oauth2-authorization-server
Version: 0.2.0

To Reproduce

1. Initiate authorization code flow
2. Exchange authorization code with access token & refresh token
3. Invoke token invocation API using access token
4. Generate new access token by exchanging refresh token
5. Use new access token and calling APIs (via resource server)

The following is response gotten from resource server:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", error_description="Provided token isn't active", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"

Expected behavior
The new generated access token is useable

Potential Codes that caused the Issue

During token revocation, OAuth2TokenRevocationAuthenticationProvider leverage on OAuth2AuthenticationProviderUtils#invalidate to add OAuth2Authorization.Token.INVALIDATED_METADATA_NAME metadata on access token.

On OAuth2RefreshTokenAuthenticationProvider#authenticate method, line 237-250, we may want to re-initiate the OAuth2Authorization.Token.INVALIDATED_METADATA_NAME metadata to false, because OAuth2Authorization#token method does inherit/copy the metadata of existing access token when we generating new access token.

// @formatter:off
OAuth2Authorization.Builder authorizationBuilder = OAuth2Authorization.from(authorization)
		.token(accessToken,
				(metadata) ->
						metadata.put(OAuth2Authorization.Token.CLAIMS_METADATA_NAME, jwtAccessToken.getClaims()))
		.refreshToken(currentRefreshToken);
if (idToken != null) {
	authorizationBuilder
			.token(idToken,
					(metadata) ->
							metadata.put(OAuth2Authorization.Token.CLAIMS_METADATA_NAME, idToken.getClaims()));
}
authorization = authorizationBuilder.build();
// @formatter:on

[ufkl]

Or maybe we should look at why we still allow to exchange refresh token for new access token?

[jgrandja]

Thanks for the report @ufkl ! This is now fixed via e4ce97b.