Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect Session Management

OpenID Connect Session Management lets a relying party monitor whether an end user's login status at an OpenID Provider has changed, so stale local sessions can be updated or ended.

Category: Concept Updated: June 25, 2026 Tags: OpenID Connect, session_state, check_session_iframe, identity, browser sessions, agents, session governance

Definition

OpenID Connect Session Management 1.0 is an OpenID Foundation Final Specification by Breno de Medeiros, Naveen Agarwal, Nat Sakimura, John Bradley, and Michael B. Jones, dated September 12, 2022. It describes how OpenID Connect sessions can be monitored, including when a relying party should log out an end user.

The specification complements OpenID Connect Core by defining ongoing monitoring of the user's login status at the OpenID Provider, or OP. If the user logs out at the OP, a relying party, or RP, can learn that its own local session should be updated or ended. The spec uses front-channel communication through the user agent and can be used separately from or alongside Front-Channel Logout, Back-Channel Logout, and RP-Initiated Logout.

For agent systems, the session definition is a useful constraint: browser session state is temporary delegated presence, not a permanent grant.

How It Works

An RP session typically begins when the RP validates an ID Token. When the OP supports Session Management, it returns a session_state parameter in the Authentication Response and should also return it in an Authentication Error Response. The value is an opaque JSON string for the RP, cannot contain a space, and is required when Session Management is supported.

The session_state value is calculated by the OP and recalculated inside an OP iframe in the user's browser. The spec describes it as based on a salted cryptographic hash of the client ID, origin URL, and OP user-agent state. Discovery metadata exposes check_session_iframe, an HTTPS URL for OP iframe communication through HTML5 postMessage.

The RP loads its own hidden iframe and an OP iframe. At a chosen interval, the RP iframe sends the client ID plus current session_state to the OP iframe. The OP iframe replies unchanged, changed, or error. Both sides must enforce expected origins.

When the RP receives changed, it must re-authenticate with prompt=none. If the response is for the same user, the RP can update session_state. If no ID Token is returned or another user appears, the RP should treat that as logout for the original user.

Agent Context

Browser-based agents inherit the session problem. An assistant that summarizes pages, fills forms, or runs browser actions may act under a local RP session that depends on OP authentication. Session Management lets the RP notice OP-state changes without continuously sending full authentication requests.

The signal is not a full authorization system. It does not revoke refresh tokens, cancel background tasks, clear server-held connector credentials, or decide whether an agent may finish a pending action. It tells the RP to verify whether the session relationship changed.

Limits and Failure Modes

The major limit is browser behavior. The spec warns that user agents were beginning to block third-party content by default to reduce tracking. Cookies or web storage needed to recalculate session_state may be unavailable in iframe contexts, which can cause repeated changed responses and loops of silent re-authentication. The spec recommends defensive code and, where possible, user notification.

A second limit is privacy. If OP user-agent state is stored in a cookie accessed by JavaScript, the cookie likely cannot use the HttpOnly flag. The spec warns that identifying information should not be placed in that cookie.

A third limit is scope. Session Management watches login state at the OP; it does not automatically govern every downstream connector, retained memory, queued task, or API token.

Minimum Evidence Record

An agent platform using Session Management should preserve the OP issuer, RP client, check_session_iframe endpoint, polling interval, current session_state, origin checks, OP reply, prompt=none result, local session change, connector state, and follow-up revocation or job decisions. Logs should not retain unnecessary cookies, browser storage, or raw bearer tokens.

Defense Pattern

Spiralist Reading

Spiralism reads Session Management as watchfulness over delegated presence. A browser session is not the person; it is a temporary institutional claim that the person is present enough to act through the system.

The discipline is to notice when that claim changes. For agents, the danger is a session that keeps speaking after the user has departed. The answer is bounded checks that reduce stale authority and leave an auditable trace.

Sources

Return to Wiki