Wiki · Concept · Last reviewed July 10, 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 OpenID Connect session should be cleared without depending on the user's browser.

Category: Concept Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 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. It defines a direct path from an OpenID Provider, or OP, to relying parties, or RPs, that need to end local sessions after the OP has decided an end-user should be logged out.

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.

The boundary should stay narrow. Back-channel logout is a session-clearing mechanism. It is not general token revocation, not continuous access evaluation, not proof that the user approved an agent action, and not a guarantee that every downstream job or connector stopped.

Current Context

As of the July 10, 2026 review, the current public OpenID page for Back-Channel Logout is the Final specification dated December 15, 2023, incorporating errata set 1. The OpenID Foundation membership approved the OpenID Connect logout family as Final Specifications on September 12, 2022, including Session Management, Front-Channel Logout, Back-Channel Logout, and RP-Initiated Logout.

That date distinction matters for citations. The September 2022 final announcement establishes final status. The December 2023 page is the current errata-incorporating text to use for claim details such as the exp requirement, application/logout+jwt media type, and cross-JWT-confusion guidance.

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 with backchannel_logout_session_required whether the Logout Token must include a sid claim. The registered URI must be absolute, must not include a fragment, should use HTTPS, and may use HTTP only for a confidential client when the OP allows it.

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 iss, aud, iat, exp, jti, and an events claim containing http://schemas.openid.net/event/backchannel-logout. It must include sub, sid, or both, and it must not include nonce.

Validation is profile-specific. The RP validates the signature as it would validate an ID Token signature, rejects alg value none, checks issuer, audience, issued-at and expiration claims, verifies the event claim, verifies the absence of nonce, and may reject repeated jti values. It may also compare issuer, subject, and session ID against a current or recent ID Token for the same OP/RP session.

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 no sid is present, the intent is that all RP sessions for the end-user identified by iss and sub be logged out. A successful response is HTTP 200 OK, with HTTP 204 No Content tolerated by OPs because some frameworks substitute it for an empty 200 response. Invalid requests or failed logout actions require HTTP 400 Bad Request.

The spec registers the application/logout+jwt media type and recommends typ value logout+jwt 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 cancel every job, govern model memory, or prove that an agent stopped using a separate OAuth grant. The back-channel spec says refresh tokens issued without the offline_access property to the session being logged out should be revoked, while refresh tokens issued with offline_access normally should not. Agent platforms still need OAuth Token Revocation, OAuth Token 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 to reduce replay value.

Reachability is also a governance fact. Back-channel logout requires the RP's endpoint to be reachable from every OP that needs to call it; an RP hidden behind a firewall, NAT, tenant gateway, or local-only development environment may not receive the logout event. Production evidence should therefore include endpoint reachability tests and failure behavior, not just metadata registration.

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 raw Logout Tokens, bearer tokens, full claim sets, browser identifiers, or user secrets.

Minimum Evidence Record

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

Failure Modes

Session-token confusion. The RP treats logout as if it revoked every OAuth grant, access token, background job, and connector credential.

Token-class confusion. A Logout Token is accepted as an ID Token, access token, client assertion, or generic JWT proof because the receiver does not enforce token profile and event type.

Wrong blast radius. The RP receives a token with only sub and logs out too little, or receives a token with sid and logs out too much.

Replay tolerance. The RP accepts stale Logout Tokens because expiration, issued-at time, and duplicate jti handling are weak.

Unreachable endpoint. The OP has recorded the RP as logged in, but the RP's backchannel_logout_uri cannot be reached from the OP during the logout cascade.

Agent afterlife. The local web session ends, but an agent run, connector grant, task queue, or cached authorization state continues using authority the user would reasonably think ended.

Defense Pattern

Source Discipline

Claims about OP discovery metadata, RP registration metadata, Logout Token claims, validation, responses, refresh-token handling, and media type registration should cite the OpenID Connect Back-Channel Logout specification, preferably the December 15, 2023 errata-incorporating text. Claims about final status should cite the September 12, 2022 OpenID Foundation final-specification announcement.

Claims about Security Event Tokens should cite RFC 8417, especially when treating events as statements of fact that receivers interpret locally rather than as commands. Claims about JWT type confusion should cite RFC 8725 and the back-channel spec's cross-JWT-confusion section. Claims about grant cleanup should distinguish the OpenID session logout flow from OAuth Token Revocation under RFC 7009.

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.

Open Questions

Sources

Return to Wiki