Currently when access-token is issued and this access-token is later sent to some Keycloak endpoint (For example OAuth2 introspection endpoint, OIDC UserInfo endpoint, Account/Admin REST API), Keycloak needs to verify the token and check if it is still valid, user has proper roles to invoke account/admin REST API etc.

For this verification, Keycloak currently may not be as effective due the fact that access-token JWT does not have some "context" needed. For example:

• Access token has sid claim, which allows Keycloak to validate user-session and check if session still exists and is valid. However it is not clear if it is "online" user session or "offline" user session. So we eventually need to try lookup both (See UserSessionUtil.findValidSession ) . If we know the session-type, we can lookup just the proper session type (offline or online) without need to check both (Both security and performance advantage).

• It is not 100% clear if access-token is lightweight access token or not. There are some ways to detect this (like looking at the sub claim present or roles present in the token), but possibly not 100% reliable

• If we know the grant, it can allow us to skip some checks for specific grants. For example for token-exchange, we may not possibly have client-session available in the user-session and hence we may skip check for client-session existence (Related task Can we avoid creating client-session for the case when access-token requested? #37117 ).

Details

We had some discussion about “encoding of context to the access token” . So when access-token is issued, there will be a way to add some small info to the ID of the access-token. Stuff is encoded to the ID, so we don’t need dedicated non-standard claim on the access-token.

Some examples:
id: "on:123" - Access token created from “online” session
id: "off:123" - Access token created from “offline” session
id: "te:123” - Access token created from token-exchange grant
id: "ac:123" - Access token created from authorization-code grant
id: "lat:123" - Lightweight access token
id: "rat: 123" - Regular access token

We may possibly need to add all of those to the token, so it may be something like:
id: "on_te_rat:123 - Regular access token from "online" user session and token-exchange grant

NOTE: The old format ID is still needed to be supported due the persistent sessions (As token from old format can be still valid after server restart).