Your app ends its own session, then redirects the user to the identity provider's end_session_endpoint, usually with an id_token_hint and a registered post_logout_redirect_uri. The provider may ask the user whether to sign out there too, and may notify other apps. Logging out of your app alone leaves the provider session alive.
Two sessions, not one
When someone signs in through OpenID Connect, two sessions exist: one in your app and one at the provider (the OP). If you only delete your own cookie, the next click on "Sign in" signs the user straight back in, because the provider still trusts them. On a shared computer that is a real problem.
The OpenID Connect RP-Initiated Logout spec describes how an app, called the relying party (RP), asks the provider to end its session too.
The request
The RP redirects the user's browser to the provider's logout endpoint, normally found as end_session_endpoint in the discovery document. The spec defines these parameters:
| Parameter | Status | Purpose |
|---|---|---|
| id_token_hint | Recommended | A previously issued ID token that identifies who is logging out |
| client_id | Optional | Identifies your client, useful when there is no hint |
| post_logout_redirect_uri | Optional | Where to send the user afterwards |
| state | Optional | Passed back to your redirect to keep your place |
| logout_hint, ui_locales | Optional | Hints for the provider's logout page |
The post logout URL must be registered with the provider beforehand. The spec also recommends sending an id_token_hint whenever you include a redirect. The spec also says the provider must not redirect unless the URL exactly matches a registered value, which keeps the logout endpoint from acting as an open redirect.
What the provider does
The provider validates that it issued the ID token. It should accept an ID token even after its expiry, as long as the client has a current or recent session. If the token's session ID does not match, the provider should treat the request as suspect and may decline it.
Then it should ask the user whether to sign out of the provider as well. It must ask if no id_token_hint was supplied. If the user agrees, the provider logs them out and uses the logout mechanisms registered by other apps, such as back channel logout, to tell them. See our post on OIDC back-channel logout.
Implementation steps
- Read
end_session_endpointfrom the validated discovery document. - Keep the ID token (or enough to rebuild the hint) for the session.
- On logout, destroy your server side session and clear cookies.
- Redirect to the logout endpoint with the id_token_hint, your client_id, a registered post_logout_redirect_uri and a fresh state.
- On return, check state, then show a signed out page. Do not auto sign in again.
- Register each possible return URL exactly, with no wildcards.
Pitfalls
- Treating the redirect as proof that logout succeeded. The spec says some notification methods are unreliable, and the user can decline at the provider.
- Using GET with sensitive values in a URL that gets logged. The spec allows POST too.
- Forgetting mobile and desktop apps, which need a registered custom or claimed URL for the return.
- Leaving refresh tokens valid after logout. Revoke them if the provider supports it.
Quick check
Is deleting my app cookie a full logout?
It ends your app session only. The provider session can remain, and a later sign in may happen without a password.
Why register the post logout redirect URI?
The spec requires it to be registered in advance. Otherwise anyone could craft a logout link that bounces users to a site of their choice.
Safeguard's SBOM and dependency scanning shows which OIDC client libraries you use, which helps when you check what logout features they support. There is a free scan.
Sources
Last reviewed: 19 October 2026.
