Additionally to the IAM default token format, Access Tokens can be issued as JSON Web Tokens (JWT). This allows the token to be self-contained and contains additional data about the authorization.
In scenarios where the same token is used on third party resources, a JWT allows avoiding OAuth 2.0 Token Introspection or resource calls, which may improve performance.
Using JWT Access Tokens bears the major risk that third parties mistake revoked/invalidated tokens to be valid.
More precisely, JWT Access Tokens may be revoked or invalidated by the user, the client or due to security reasons (e.g. token refresh, replay attack detection, single-use access tokens, etc.). In this case, without making a call to the Authorization Server, a third party will never learn that the token was revoked and will mistake it to be valid because the JWT is technically valid.
Consider the following countermeasures:
- To avoid this problem completely, tokens must be validated using Token Introspection calls to the Authorization Server.
- To counteract the issue to a certain extent, we recommend using short access token validity times.
Third parties receiving a JWT Access Token must validate it according to current security best practices (signature validation, validation of Registered Claims, etc.), or use the OAuth 2. 0 Token Introspection Endpoint to verify the validity.
Revoked/invalidated JWT Access Tokens cannot be used on Airlock IAM endpoints (e.g. OAuth 2.0 Token Introspection), even if the token's content implies it's validity.