Token Revocation serves the purpose of invalidating an existing access token when a user's status is demoted, ensuring that users cannot continue using their old access tokens to access restricted resources. In this system, token revocation is achieved by leveraging the JWT Token Identifier (JTI) and a caching mechanism.
_NOTE: Token revocation is a server-side mechanism and does not rely on the client (web application) to clear the access token from it's storage. Clients are encouraged to clear tokens as a best practice, but the server remains the ultimate authority for controlling access to protected resources.
- Each Access token generated by JwtUtility within the system contains a claim
jtiwhich acts as an unique identifier for the token. - When an authenticated user invokes the
/users/deactivateAPI endpoint, in addition to updating the user's status toDEACTIVATEDin the datasource, UserService also revokes the user's access token which contains enhanced privileges. - To achieve token revocation, the TokenRevocationService extracts the JTI from the Access token and stores it inside the provisioned cache. The JTI is stored as a key, and its Time To Live (TTL) is calculated based on the token's expiration time.
- Any subsequent HTTP requests with the revoked access token are rejected by the JwtAuthenticationFilter. The filter extracts JTI from the received JWT and validates it's presence in the cache. If found, further security evaluations are not performed and the request is rejected, ensuring that revoked access tokens are denied access to protected resources.
NOTE: Token revocation introduces a form of statefulness to the otherwise stateless nature of JWTs. When a token is revoked, the system maintains a record of this revocation in a cache to ensure that revoked tokens are properly rejected. This statefulness is a necessary trade-off to maintain security and control over access to protected resources within a stateless JWT-based authentication system.