OIDC back-channel logout is a session termination protocol, not a logout link
Single logout is easy to describe and difficult to enforce. A user may have several browser sessions, refresh tokens, and server-side application sessions after visiting a set of connected services. An OpenID Provider that sends only a front-channel URL can fail when a browser tab is closed, blocked, or no longer controlled by the user. OpenID Connect Back-Channel Logout moves the notification directly from the provider to each relying party.
The mechanism is defined for a relying party that registers a back-channel logout URI. The provider sends a signed Logout Token to that endpoint over the back channel. The relying party validates the token and terminates the sessions it identifies. The endpoint is a security boundary, not a generic webhook. It must have strict validation and no dependence on the user's browser being present.
Validate the Logout Token
The relying party should verify the signature using the provider's published keys, reject unsupported algorithms, and confirm the issuer and audience. It should check the iat time and reject tokens outside the accepted window. The Logout Token has an events member indicating the back-channel logout event and must contain either a subject or a session identifier in the form defined by the specification.
The token must be bound to the correct client and must not be accepted as proof for a different application. Cache the token identifier for at least the token's validity window and reject a replay. These checks are ordinary JWT validation, but logout endpoints sometimes receive weaker implementations because they are treated as a convenience endpoint rather than part of authentication.
Use a dedicated verification path that cannot be confused with ID token, access token, or authorization-code handling. Token type confusion becomes less likely when each format has an explicit parser, expected claims, and allowed algorithms. A logout request should not create a new session or return user data as part of an error response.
Revoke more than the visible cookie
Deleting a browser cookie ends one local session. It does not necessarily revoke a refresh token stored on a server, an application session in a cache, or a "remember me" credential. The relying party should map the Logout Token subject or session identifier to every active session it owns and invalidate the relevant state.
When the token identifies a session, revoke that session and its refresh material. When it identifies only a subject, the application must follow its documented policy for all sessions for that user. That policy should be explicit because a single logout event may be intended to end only one session while a security response may require all sessions. Record the distinction in the application's session model.
Distributed applications need a propagation plan. A local cache may continue to accept a revoked session for its configured maximum age. Use a short cache lifetime, a shared revocation check, or a message that invalidates cached state. Test the behavior during an identity-provider key rollover, a partial outage, and the normal success path.
Design the endpoint to fail safely
The provider's request may arrive without an interactive user. Return a small deterministic response and write an audit event with the provider, subject or session reference, result, and correlation identifier. Do not put secrets or full claims into logs. Rate-limit invalid requests while allowing legitimate retries from the provider.
If the database is unavailable, the relying party should return a temporary failure so the provider can retry according to its policy. A 200 response that discards the event prevents later recovery. If the application cannot map the subject because the account was already deleted, record the event and treat the session as terminated when no active session exists.
An outage must not become an authorization bypass. If revocation is external and the application treats an unavailable check as allowed, a stolen session survives the incident. The safer default depends on the application's risk. For administrative and financial systems, fail closed for high-impact actions and preserve a local emergency access path.
Exercise logout as an incident response control
Create two browser sessions and one refresh-token client for a test user. Send a valid back-channel logout event and verify that the selected session or user-wide set is revoked. Replay the token, change its audience, alter a byte in the signature, and send an expired token. Each must fail without returning session details.
Then simulate a provider outage and a database delay. The test should show whether the application retries, fails closed, and preserves enough evidence to recover. A successful logout test provides evidence that a validated event removed the authority a user no longer should have.
Top comments (0)