OpenID Connect Front-Channel Logout

Definition

OpenID Connect Front-Channel Logout 1.0 is an OpenID Foundation Final Specification by Michael B. Jones, dated September 12, 2022. It defines a logout mechanism in which an OpenID Provider, or OP, communicates with relying parties, or RPs, through the user's browser rather than by direct server-to-server calls.

The mechanism is deliberately simple. An RP registers a URL that will cause the RP to clear its local session when loaded. When the OP logs the user out, it renders that URL for each logged-in RP, commonly as an iframe. The RP can then clear browser-visible state such as cookies and web storage.

For agent systems, logout is a boundary event. After the user's session ends, browser-resident authority should not remain silently available to assistants, connectors, or web apps.

How It Works

An RP that supports front-channel logout registers a frontchannel_logout_uri. The spec requires that this URL be absolute, have no fragment, and share the same scheme, host, and port as one of the RP's registered redirect URIs. With dynamic registration, frontchannel_logout_session_required says whether the RP requires session identifiers.

When the OP triggers logout, it renders the registered URI in an iframe. The RP is expected to clear state associated with the logged-in session, including cookies and HTML5 local storage. If the end user is already logged out at the RP, the request is considered successful.

The OP may append two query parameters: iss, the issuer identifier, and sid, the session identifier. If either parameter is included, both must be included. The RP may verify that those values match the iss and sid claims in an ID Token issued for the current or recent session and may ignore mismatched requests.

The OP advertises support with discovery metadata. frontchannel_logout_supported indicates HTTP-based logout support, and frontchannel_logout_session_supported indicates whether the OP can pass issuer and session ID values and include the sid claim in ID Tokens.

Agent Context

Front-channel logout matters wherever an agent depends on a browser session. A browser-based assistant may summarize pages, fill forms, or submit actions using the user's logged-in state. If logout only affects the identity provider while relying-party cookies remain usable, the system keeps authority the user may believe has ended.

The mechanism is not a complete revocation system. It clears RP session state through a browser-mediated path. It does not revoke refresh tokens, cancel background jobs, close API sessions held by server connectors, erase model memory, or decide whether an agent may finish a pending action. Those controls belong to token revocation, introspection, sender constraints, shared signals, audit trails, and task policy.

Limits and Failure Modes

The main limit is reliability. The specification warns that user agents were beginning to block third-party content by default to reduce tracking. A logout iframe from the OP may be treated as third-party content, preventing access to cookies or web storage needed to clear the local session. The spec recommends defensive code and user notification where logout could not be completed.

Another limit is validation. If iss and sid are used, the RP should compare them with claims from the relevant ID Token. Treating every iframe load as authoritative can confuse session handling or enable local logout abuse.

A third limit is scope. Front-channel logout can end a browser session, but it does not automatically inform every downstream system. Agent platforms need explicit policy for connectors, queued tasks, retained memories, and long-running jobs.

Minimum Evidence Record

An agent platform using front-channel logout should preserve the OP issuer, RP client, registered logout URI, presence of iss and sid, validation outcome, browser state cleared, local session affected, blocked-content failures, user notification status, connector state after logout, and follow-up revocation or job-cancellation decisions. Logs should not retain unnecessary cookies, storage contents, or raw bearer tokens.

Defense Pattern

• Register narrowly. Use a specific frontchannel_logout_uri that only performs logout work and has no unrelated side effects.
• Require session context where useful. Prefer iss and sid for multi-session or high-risk RPs.
• Detect iframe failure. Treat blocked third-party state as a real logout uncertainty, not as cosmetic browser behavior.
• Pair with deeper revocation. Clear browser state, then separately revoke tokens, stop jobs, and close agent connector sessions where policy requires it.
• Keep a receipt. Record whether logout reached each RP, what changed, and what remained active.

Spiralist Reading

Spiralism reads front-channel logout as a visible ritual of departure. A login lets many systems treat a person as present. A logout page that fans out to relying parties says that presence should be unwound, not merely hidden behind a new screen.

The ritual is imperfect because the browser is contested ground. Privacy defenses, storage rules, iframes, and session cookies all shape whether the ending lands. The governance lesson is to verify that authority has been reduced after the user asked to leave.

Related Pages

• OpenID Connect
• OpenID Connect Back-Channel Logout
• OpenID Connect RP-Initiated Logout
• Shared Signals Framework
• OAuth Token Revocation
• OAuth Token Introspection
• Sender-Constrained Tokens
• AI Agent Identity
• AI Audit Trails

Sources

• M. Jones, OpenID Foundation, OpenID Connect Front-Channel Logout 1.0, Final Specification, September 12, 2022.
• OpenID Foundation, The OpenID Connect Logout specifications are now Final Specifications, September 12, 2022.
• M. Jones and J. Bradley, OpenID Foundation, OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1, for contrast with direct server-to-server logout.
• M. Jones, B. de Medeiros, N. Agarwal, N. Sakimura, and J. Bradley, OpenID Foundation, OpenID Connect RP-Initiated Logout 1.0, for the complementary relying-party initiated end-session flow.

Return to Wiki