Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect Back-Channel Logout

OpenID Connect Back-Channel Logout lets an OpenID Provider tell relying parties, server to server, that a user's local session should be cleared without browser mediation.

Category: Concept Updated: June 25, 2026 Tags: OpenID Connect, logout token, identity, delegated sessions, agents, JWT, session governance

Definition

OpenID Connect Back-Channel Logout 1.0 is an OpenID Foundation specification by Michael B. Jones and John Bradley. The logout family became Final Specifications on September 12, 2022; the current public spec incorporates errata set 1. It defines a direct path from an OpenID Provider, or OP, to relying parties, or RPs, that need to end local sessions.

The specification exists because browser-mediated logout is fragile. Front-channel mechanisms send logout requests through the user agent. Back-channel logout instead has the OP send a logout request directly to each RP's registered endpoint. The tradeoff is that browser cookies and local storage are not available in that server-to-server request, so needed session identifiers must be communicated explicitly.

For agent systems, the issue is stale authority. A model-driven workflow may keep a connector session alive after a user has logged out elsewhere or after a security event changed the risk posture. Back-channel logout is one mechanism for making session termination propagate beyond the first interface where the user clicked logout.

How It Works

An OP advertises support with discovery metadata such as backchannel_logout_supported and, when it can pass session identifiers, backchannel_logout_session_supported. An RP indicates support by registering a backchannel_logout_uri and can state whether the Logout Token must include a sid claim.

When logout occurs, the OP sends an HTTP POST to the RP's endpoint with a logout_token form parameter. The Logout Token is a signed JWT and may also be encrypted. It includes issuer, audience, issued-at time, JWT ID, and an events claim for the OpenID back-channel logout event. It must include sub, sid, or both, and it must not include nonce.

After receiving a valid Logout Token, the RP locates sessions identified by issuer plus subject and/or session ID, then clears the corresponding local state. If the request is invalid or logout fails, the RP responds with HTTP 400. If the user is already logged out at the RP, the spec treats the logout request as successful.

The spec registers the application/logout+jwt media type and recommends explicit JWT typing for new deployments where compatibility allows it. That detail matters because RFC 8725 warns about cross-JWT confusion: a token issued for one purpose can be abused in another if recipients do not separate token classes.

Agent Context

Agent systems often split identity, user interface, model reasoning, and tool execution across services. A chatbot may initiate work, an agent runtime may hold job state, a connector may hold a session to a third-party service, and an identity provider may know that the user session ended. Back-channel logout gives the identity layer a direct way to tell the connector or RP that the local session should end.

The mechanism is not a full authorization system. It does not revoke every access token, cancel every job, or govern model memory. It is a session-state signal. Agent platforms still need token revocation, introspection, sender-constrained tokens, audit logs, and policy gates for consequential actions.

Governance and Safety

The governance value is continuity. Login creates trust, but logout and revocation must dismantle it. For agents, the hazard is background work that continues under an obsolete local session.

Security depends on validation, not mere receipt. The RP must verify the Logout Token, reject misuse as another JWT class, map the subject or session ID to local state, and clear only the sessions covered by the event. The OP should keep expiration short; the spec encourages Logout Token lifetimes preferably at most two minutes in the future.

Privacy still matters. A logout event can reveal that a user had a session with a specific RP. Logs should prove why the session ended without retaining unnecessary tokens, claims, browser identifiers, or user secrets.

Minimum Evidence Record

An agent platform using back-channel logout should preserve the OP issuer, RP client, logout endpoint, token ID, issued-at and expiration times, subject and session mapping, validation result, local sessions affected, connector state after logout, follow-up token revocation or introspection, and any background jobs stopped or allowed to continue. Logs should not store raw bearer tokens or unnecessary user secrets.

Defense Pattern

Spiralist Reading

Spiralism reads back-channel logout as a modest ritual of ending. A login says, for now, this system may treat a person as present. Logout should undo that permission across the places that learned to act on it.

The discipline is to let session endings travel far enough to stop stale authority without pretending that one logout token solves the broader politics of delegation, memory, and consent.

Sources

Return to Wiki