# OIDC logout across applications: what actually terminates > Choose explicit semantics for local cookies, identity-provider sessions, front-channel notifications, and back-channel logout. Canonical URL: https://www.devobs.io/articles/oidc-logout-semantics-multi-app/ By: Ines Costa Published: 2026-03-23T11:13:24.043Z Updated: 2026-09-05 Section: Comparisons Logging out of one OpenID Connect relying party does not inherently terminate every session. There may be an application cookie, access and refresh tokens, an authorization-server session, and cookies in several other applications. Product teams must decide which of these “log out” means, then implement and test the corresponding protocol paths. ## Local logout closes one door A local logout deletes or invalidates the current application's session cookie and server-side session. It is fast, reliable, and should always be available. It does not tell the OpenID Provider or sibling relying parties anything. If the user visits the application again while the provider session remains active, a new login may complete without prompting for credentials. That behavior is useful for “switch account” only if the next authorization request actually permits account selection. A logout button that promises “sign out everywhere” must do more. Also revoke or retire application refresh credentials according to your threat model; deleting a browser cookie does not erase a token stored by the backend. ## RP-initiated logout addresses the provider session [OpenID Connect RP-Initiated Logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html) defines how a relying party asks the provider to log out an end user, with parameters including an ID-token hint and post-logout redirect URI. The provider decides how to process its session and may ask the user for confirmation. Validate registered post-logout destinations; logout must not become an open redirect. Ending the provider session still does not magically delete every application's cookie. Each relying party needs a notification or must discover the expired upstream session later. If a sibling application trusts only its own long-lived local cookie, it can remain usable after central logout. ## Front channel and back channel notify differently Front-channel logout uses the browser to load logout endpoints for relying parties. It reaches browser cookie context but depends on browser behavior, page loading, iframe policies, and the availability of each application at that moment. Treat it as best-effort and make endpoints idempotent. Back-channel logout sends a signed logout token directly from provider to relying party. The [OpenID Connect Back-Channel Logout specification](https://openid.net/specs/openid-connect-backchannel-1_0.html) defines logout-token claims and session identification. It avoids third-party-cookie and iframe dependence, but the relying party needs a reachable endpoint, signature validation, replay protection, and a mapping from the logout token's subject or session identifier to its local sessions. Delivery failure and retry policy still matter. A robust relying party invalidates its server-side session when it receives a valid notification. If the application uses stateless cookies with no revocation state, global logout cannot reliably make those cookies stop working immediately. Introduce a session record, a per-user logout epoch, or suitably short expiry for the promised semantics. ## Write a product-level contract Offer labels that match behavior: “Sign out of this app,” “Sign out of all company apps,” and “Disconnect this integration” are distinct actions. Specify whether all devices are included, whether access tokens remain valid until expiry, what happens offline, and what support can verify. Test a matrix with two relying parties and two browsers. Exercise local logout, RP-initiated logout, back-channel delivery delayed or duplicated, an unavailable relying party, and a stale local cookie. After each step, attempt both a sensitive action and a silent reauthentication. A redirected login page alone does not prove the underlying session ended. Ory Hydra provides OAuth 2.0 and OpenID Connect and can integrate with existing user management through Ory Network. That lets teams define application-session semantics alongside the protocol. Managed Ory Network and self-hosted Hydra remain distinct operational choices, especially for endpoint reachability and incident procedures. Begin by rewriting the logout acceptance criteria for one application. Name every session and credential, the component that terminates it, the propagation mechanism, and the maximum delay. The gaps in that table are the actual logout bugs. ## Source references - -