Description
Description
Issue description
After upgrading our Keycloak server to 26.2.5 from 26.1.4, we began seeing the “Do you want to log out?” confirmation page in situations where it never appeared before.
What triggers it
The refresh-token call (grant_type=refresh_token) fails with 400 invalid_grant because the user’s session has already expired (idle or max-life reached).
keycloak-js responds by calling clearToken(), which deletes token, refreshToken and idToken from memory.
Our code then calls keycloak.logout({ redirectUri }). Because idToken is now undefined, the adapter builds a logout URL that contains only
client_id + post_logout_redirect_uri (no id_token_hint).
From Keycloak 26.2+ onwards the server follows the OIDC RP-Initiated Logout spec strictly: if a session is still present and no id_token_hint is supplied, it must ask the user to confirm. Hence we now get the confirmation page which was an unexpected change that required a 'monkey patch' on the SPA app .
Expected behaviour
keycloak.logout() should always attach id_token_hint when it can still identify the user (e.g. by caching the last ID token), so that logout remains silent and consistent with pre-26.2 behaviour.
Actual behaviour
Whenever a refresh-token failure has triggered clearToken(), the subsequent logout lacks id_token_hint and the browser sees the confirmation screen.
Suggested fix
Either modify createLogoutUrl() to fall back to the last successfully issued ID token (even if it is expired), or
Add an adapter option such as preserveIdTokenOnRefreshError / alwaysSendLastIdTokenHint so apps can opt in to sending the hint.
Current work-around
Cache keycloak.idToken in sessionStorage on every successful login/refresh and monkey-patch createLogoutUrl() to insert that cached value when kc.idToken is undefined. This restores silent logout but requires custom code in every SPA.
Discussion
No response
Motivation
No response
Details
No response