Description

When the access-token is sent to some Keycloak endpoints (EG. introspection endpoint, user-info endpoint admin/account REST API), we currently verify if user-session, which is linked to that token, exists (unless token comes from client-credentials grant, which does not use user sessions).

The issue is, that we don't know if token is coming from offline session or "online" session. So currently we try to lookup "online" and then fallback to offline just if "online" not found. This can be optimized and made more secure if we know session type. In that case, we can lookup only the correct session type and lookup either only "online" or only "offline" .

The info about session-type would be available in the token after #37118, so this issue is probably the follow-up after that one.

Related code where the sessions are looked-up:

• UserSessionUtil.findValidSession - used by introspection endpoint and user-info endpoint
• AuthenticationManager.verifyIdentityToken - used by account REST and admin REST APIs (used maybe by more token types, not just access token. So should be doublechecked and maybe dedicated signature used to optimize session lookup just when used with the access-token. But not sure as the type UNKNOWN, so when token ID is just UUID, it would work as well even if won't be so optimal...)

Related note: RefreshTokenIntrospectionProvider might probably override some method for session lookup, so session lookup would be optimized as well. With #37118, the session-type is not encoded to refresh-token as that issue is specific to access-tokens only. However it is not needed for refresh-token as refresh-token has the type claim with the value Refresh or Offline, so for refresh-token it is already clear if it should lookup "online" session or offline session. The optimized lookup is used during refresh-token request where it lookups only proper session type. We can do similar in RefreshTokenIntrospectionProvider as well, so it does not need to "fallback" and lookup both online and offline.