Describe a robust strategy for handling token revocation in a Spring Security application using OAuth 2.0, considering both JWTs and opaque tokens.
Java interview question for Advanced practice.
Answer
A robust token revocation strategy depends on the type of token being used: 1. Opaque Tokens: Revocation for opaque tokens is straightforward and a key advantage of this approach. Since every API call requires the resource server to check the token with the authorization server (via an introspection endpoint), the revocation is immediate. Strategy: The authorization server maintains the state of all issued tokens in its database. To revoke a token, you simply delete it or mark it as invalid in the database. The next time the resource server introspects that token, the authorization server will correctly report it as invalid. 2. JSON Web Tokens (JWTs): Revocation is more complex for JWTs because they are stateless. A resource server validates them without contacting the authorization server, so it has no way of knowing if a token has been revoked after being issued. Strategy (The Blacklist): The most common strategy is to reintroduce a small amount of state. When a token is revoked, its unique identifier (the jti claim) is added to a 'blacklist'. This blacklist must be checked by the resource server on every request. Implementation: The blacklist should be stored in a very fast, shared cache (like Redis or Memcached) to minimize the performance impact. The resource server's security filter is customized to perform this check after validating the token's signature but before granting access. JWT - Validate Signature - Check Blacklist - Grant Access The entry in the blacklist only needs to be stored until the token's natural expiration time, so the list doesn't grow indefinitely.
Explanation
The OAuth 2.0 Token Revocation specification (RFC 7009) defines a standard endpoint on the authorization server that clients can use to signal that a specific token (access or refresh) is no longer needed.