Expected Behavior

When revoking a refresh token, the authorization builder should safely invalidate any associated tokens (such as access tokens or authorization codes) only if they exist.

If the access token is not present in the authorization’s token map (for example due to token rotation, cleanup, or custom authorization storage strategies), the revocation process should continue without throwing an exception.

The revocation operation should be null-safe and should not assume strong consistency between refresh tokens and access tokens.

⸻

Current Behavior

During refresh token revocation, OAuth2Authorization.Builder.invalidate() attempts to invalidate the associated access token without performing a null check:

Token<?> accessToken = this.tokens.get(OAuth2AccessToken.class);
token(accessToken.getToken(), metadataConsumer);

If the access token is absent, this results in a NullPointerException, causing the revocation flow to fail.

Notably, similar logic for OAuth2AuthorizationCode includes proper null and invalidation checks, making the current behavior inconsistent.

⸻

Context

In real-world deployments, it is common for access tokens to be removed or not present when a refresh token is revoked. This can occur in scenarios such as:
• Refresh token rotation with reuseRefreshTokens=false
• Authorization/token cleanup jobs that remove expired access tokens
• Custom OAuth2AuthorizationService implementations (e.g., Redis or JDBC pruning strategies)
• Interrupted or partial authorization flows

This issue affects stability of the /oauth2/revoke endpoint, as revocation requests may fail with a server error instead of completing successfully.

As a workaround, applications may need to implement custom defensive logic or override authorization handling to ensure null-safety during token invalidation.