Allow Token Revocation to be customized

[arfatbk]

Expected Behavior
Successful refresh Token Revocation should provide a token blocklist implementation for all related access tokens. Or Raise an Event, which then can be consumed to implement a custom token blocklist.

Current Behavior
After Refresh Token revocation, the access token remains valid and can be used by OAuth2 Resource servers.

Context
If we go with the 'Event' approach, after successful revocation of a refresh token, developers can implement blocklist as in memory, JDBC, Communicate over MQ.

I am using the OAuth Resource server that validates access token using the OAuth server's JWKs keys. After Refresh Token is revoked, There seems no way to communicate this to the OAuth Resource server. AFAIK @jgrandja please correct me or point me in the right direction. Thanks

[jgrandja]

Thanks for getting in touch @arfatbk.

Spring Authorization Server does revoke the associated access token during a refresh token revocation (see test), but the JWT access token can still be used at the Resource Server, if the Resource Server verifies the token locally instead of calling the Introspection Endpoint.

This is an important use case to solve and as far as I am aware, there are no RFC standards that solve this problem. The Authorization Server and Resource Server(s) would need to communicate with each other so that the Resource Server's are up-to-date with all revoked tokens so it can implement the blocklist.

Instead of implementing the blocklist on the Resource Server, you could call the Introspection Endpoint with the JWT to determine if it's active or not. However, this would obviously downgrade performance with that extra hop.

The goal of this framework is to implement to spec and provide customization hooks for applications to customize the standard behaviour however they choose. Given that this would be custom behaviour, we would only provide customization hooks.

@arfatbk Would you be able to do some R&D to see what other providers have implemented to solve this problem?

[arfatbk]

Thanks for your response. I will look for references.

[arfatbk]

I am not able to find exact implementation by other providers. Closest I could manage is to route revocation request though Spring Cloud Gateway and on successful revocation, propagate the event to all resource servers.

Resource servers may store this in memory blacklist or Centralized cache.

I think this is interesting use-case. We certainly don't want to call OAuth server on each request to validate token, or go to database either.

OAuth server should have a hook to provide onTokenRevocationSuccess() or make token revocation configurable.

[jgrandja]

@arfatbk

OAuth server should have a hook to provide onTokenRevocationSuccess()

I'll get back to you after I've thought of an approach to implement this.

[arfatbk]

I'll be more than happy to contribute. Thanks

[jgrandja]

Sounds good @arfatbk 👍

[jgrandja]

@arfatbk We could add OAuth2TokenRevocationEndpointFilter.setAuthenticationSuccessHandler(AuthenticationSuccessHandler), which would provide the hook you're looking for. It would be a similar implementation as OAuth2TokenEndpointFilter and it's OAuth2TokenEndpointConfigurer. How does this sound?

[arfatbk]

Cool. Sounds great.👍