Invalidate access token

1

How can an access token be invalidated after a new access token is issued for the same session?

Is there a way to call the /protocol/openid-connect/revoke endpoint with old access token when a new access token is issued?

2

Have you considered implementing this requirement with off-the-shelf session functionality? Use a cloned Authenticator and add a “User session count limiter” of 1 where the behavior is “Terminate oldest session”.

The specific sequence of steps is

  1. Duplicate the browser or direct grant Authenticator
  2. Add a step “User session count limiter” at the end
  3. Set the “User session count limiter” property to 1 realm session
  4. Set the “User session count limiter” property behavior to “Terminate oldest session”

Good luck,
Carl

3

What do you want to achieve with this? It would probably break any SSO usage (multiple clients requesting tokens for the same keycloak session is the typical usecase).
Did you consider making the tokens shortlived ( and use the refresh token flow)?

4

We are not using SSO. We need to invalidate the old access token once its refreshed using refresh token

5

in this case in a single session multiple valid access token can be present. Can we invalidate the old access token once the new is generated?

6

That requirement is picked up in my suggestion to limit the # of sessions. Setting this to one means that there’s only one active session maintained by terminating the oldest session.

IMO, it’s easier better to use KC’s session management rather than code one or more apps to track sessions across themselves and make API calls that might require increased privileges.

7

If the token is shortlived (say, 30s.) then your gain from invalidating the old token is rather limited.

8

@Carl limiting sessions to 1 is not the same as having only 1 valid access token.
The approach @bpedersen2 mentioned of having very shortlived token lifetimes is a good one.

A bit more explanation:
With JWT as token format, a token introspection at the server is no more mandatory, as the JWT is self-contained and offline verifyable. I only need the public key to verify the signature. If this is valid and the exp claim value in the payload is not expired, I may use the token without further verification at the issuing server. So, invalidating a JWT access token is kind of useless.

1 Like