Before reporting an issue

[X] I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

oidc

Describe the bug

With latest Keycloak main, it can happen this:

1) User authenticates to client foo. SSO session with ID session1 is created. Access token and refresh token are issued
2) User authenticates to client foo with scope=offline_access . Offline session with same ID session1 is created
3) Revocation request is sent with the offline token from step 2
4) Introspection request sent with the access-token from step 2. Now it would be expected that access-token is revoked, but it is not right now. Introspection is successful -> KO

NOTE: In case that step (1) is omitted and there is no "online" session, things work as expected and access-token is properly revoked in (4).

This is regression of the change https://github.com/keycloak/keycloak/issues/35486

Cause

When access-token is sent to introspection endpoint, it is checked that related session session1, which is referenced by the session_state claim of access token, exists. The offline session was removed in step (3). However there is still "online" session existing with the same ID session1 . This would cause that access-token is considered as successful even if it should be revoked -> KO

Possible solutions

1) Make sure that in case that offline-token is sent with session1, it will revoke both offline and online session. This was the case before https://github.com/keycloak/keycloak/issues/35486

2) Make sure that online and offline session always have different IDs. Probably best approach from the long-term. However it can cause regressions, so likely not ideal to do in short before Keycloak 26.1 release. Also https://github.com/keycloak/keycloak/issues/35486 should be backported to 26.0 and 24.0 (requested by customers), but refactor session IDs in 26.0 and 24.0 might be too invasive change

3) Add some claim into access-token like session-type to signal whether the access-token was issued by online session or offline session. Introspection endpoint can then check the session-type . Maybe be nice as an optimization (especially due the introspection endpoint won't need to lookup both offline and online session). But probably also as a follow-up?

4) Something else?

My vote is (1) as it is easiest from the short term perspective and will work fine with backports.

Version

nightly (from 2024-12-11)

Regression

[X] The issue is a regression

Expected behavior

Access token issued in step 2 is revoked

Actual behavior

Access token issued in step 2 is not revoked

How to Reproduce?

See the description

Anything else?

No response