What is Back-channel logout?
OpenID Connect Back-Channel Logout lets an OpenID Provider notify a relying party through a direct server-to-server request. The notification carries a signed logout token. The relying party validates the token and clears the session identified by its issuer, audience, and session or subject claims. This method does not depend on the user's browser, but every relying party must expose and secure a compatible logout endpoint.
Why it matters
A browser can close or block a front-channel notification. A direct logout request gives an OpenID Provider another way to tell each relying party to end a session.
How it works
- The OpenID Provider determines which relying-party sessions are part of the logout event.
- It sends a form-encoded POST with a signed logout token to each registered back-channel logout URI.
- Each relying party validates the token and clears the session identified by the issuer, audience, and session or subject claims.
Example
A user signs out at the identity provider. The provider sends a logout token to the payroll relying party, which validates the token and deletes the matching local session.
Pomerium boundary
Pomerium documents OpenID Connect Front-Channel Logout through the /.pomerium/sign_out path. If a protected application also needs Back-Channel Logout, its OpenID Connect client must expose and validate the back-channel endpoint. Do not treat Pomerium's front-channel path as that endpoint.
Limits and non-claims
- Every relying party must keep a reachable and authenticated logout endpoint.
- A logout token ends the identified local session but does not by itself revoke every access token.
- Delivery can fail, so the provider and relying party need defined retry and session-expiry behavior.
Evaluation checklist
- Does the relying party validate the logout token issuer, audience, events, identifier, and time?
- Which subject or session identifier selects the sessions to terminate?
- How do retries, replay, missed delivery, and partial logout appear in evidence?
