Skip to content

Coordinated Logout With Front-Channel And Back-Channel Notifications

Login is only half of the session story. In a single application, logout can look simple: remove the local cookie, clear local state, and send the user back to a signed out page. In an OpenID Connect deployment with...

Technical note8 min readmarc-mueller
Back to blog

Login is only half of the session story.

In a single application, logout can look simple: remove the local cookie, clear local state, and send the user back to a signed-out page. In an OpenID Connect deployment with several relying parties, that is only application logout. The user may still have an active identity-provider session, and other client applications may still have their own local sessions.

That distinction is where many single sign-out designs become vague. Users expect “sign out” to mean the session is over. Applications, browsers, and identity providers each hold different pieces of that session. A reliable design has to coordinate those pieces without pretending that one HTTP redirect can control every application instantly.

ProAuth 3.0.0 expands logout interoperability with both back-channel logout and front-channel logout support. The release notes describe the product-level change: ProAuth can send signed server-to-server logout notifications to registered client applications and can also trigger browser-based notifications through hidden iframes for broader session termination coordination.

Application Logout Is Not The Same As OP Logout

Application logout terminates the local session for one client application. The application may delete its own authentication cookie, remove a server-side BFF session, revoke local cached state, and redirect the browser away from protected pages.

Identity-provider logout terminates the user’s session at ProAuth, the OpenID Provider. That matters because the ProAuth browser session is what lets the user move between participating clients without authenticating again. If only one application signs the user out locally, another application may still have a valid local session, and ProAuth may still be able to authenticate the user silently or with little friction depending on the active flow.

OpenID Connect RP-Initiated Logout defines the pattern where a relying party asks the OpenID Provider to log out the end user through the OP logout endpoint. Once the OP logs the user out, it can use registered logout mechanisms to notify relying parties that participated in that user’s OP session.

That last phrase is important. Logout coordination is scoped to registered client applications and active session participation. It is not a broadcast to every application that has ever existed in the tenant.

Back-Channel Logout Sends Signed Server-To-Server Notifications

Back-channel logout is the stronger default for enterprise single sign-out because the notification does not depend on the browser loading another application’s page.

With ProAuth back-channel logout, a registered client application configures a backchannel_logout_uri. When the ProAuth browser session ends, ProAuth sends an HTTP POST directly to each enabled client application that participated in the same OP session and has a back-channel logout URI configured. The request uses the standard form shape:

logout_token=<signed JWT>

The logout_token is the security boundary. ProAuth signs it with the signing keys published through its JWKS endpoint and uses the logout+jwt type. The receiver validates the token as it would validate other issuer-signed protocol tokens, with logout-specific checks: issuer, audience, lifetime, jti, the back-channel logout event, sid when present, sub when present, and the absence of a nonce.

The official OpenID Connect Back-Channel Logout 1.0 specification defines the same core model: the OP sends a logout token to the RP’s registered back-channel logout URI, the RP validates the token, and then the RP clears the identified session state. The spec also requires the token to identify the affected session through sid, sub, or both.

ProAuth’s documentation adds the operational shape teams need in production. Back-channel logout URIs are HTTPS by default, HTTP is limited to a development/test setting for non-public clients, retryable delivery failures are persisted, and the retry job uses exponential backoff. Successful 200 OK and 204 No Content responses complete delivery. Timeouts, network failures, 408, 429, and 5xx responses are retryable. Permanent 4xx responses are not retried.

That retry behavior improves delivery reliability, but it does not make logout magic. The receiving application still has to implement the endpoint correctly, validate the token, reject replays, and remove the matching local session. In multi-instance BFF deployments, the session store and replay-protection cache need to be shared so any instance can find sessions created by another instance.

Front-Channel Logout Uses The Browser

Front-channel logout solves a different compatibility problem.

Some clients already support browser-based logout notifications, or they do not expose a server endpoint that ProAuth can call directly. For those clients, ProAuth can render hidden iframes during logout. Each iframe points to a registered frontchannel_logout_uri for a client application that participated in the same OP session.

ProAuth appends iss and sid query parameters to the front-channel logout URI. Existing query parameters are preserved, and if the configured URI already contains iss or sid, ProAuth replaces them with the authoritative logout values. The relying party can use those values to identify the issuer and session before clearing its local browser-visible session state.

OpenID Connect Front-Channel Logout 1.0 defines this iframe-based model. It is widely understood by browser applications, and it can be a practical fit when the client can clear state by receiving a browser request.

Its limitation is also explicit in the standard and in the ProAuth docs: the browser has to load the iframe, and the relying party may need access to browser state such as cookies or web storage. Browser tracking protections, third-party cookie restrictions, network behavior, blocked content, and closed tabs can affect the result. A front-channel notification is useful coordination, not a guarantee that every client session disappears at the same instant.

The Two Flows Side By Side

sequenceDiagram
    autonumber
    participant User as User
    participant Browser as Browser
    participant ProAuth as ProAuth OP
    participant FrontClient as Front-channel client
    participant BackClient as Back-channel client

    User->>Browser: Starts logout
    Browser->>ProAuth: RP-initiated or OP logout request
    ProAuth->>ProAuth: End OP browser session

    Note over Browser,FrontClient: Front-channel notification depends on the browser
    ProAuth-->>Browser: Logout page with hidden iframe
    Browser->>FrontClient: GET frontchannel_logout_uri with iss and sid
    FrontClient-->>Browser: Clear local browser session if reachable

    Note over ProAuth,BackClient: Back-channel notification is server-to-server
    ProAuth->>BackClient: POST signed logout token
    BackClient->>BackClient: Validate token and remove matching session
    BackClient-->>ProAuth: 200, 204, or retryable failure

The front-channel path keeps the browser in the middle. That can be good for client applications that are built around browser-local state, but it inherits browser constraints.

The back-channel path moves the notification to the server side. That is usually better for confidential server-side applications and BFFs because the server can receive a signed token, validate it, remove server-side sessions, and let ProAuth retry recoverable delivery failures.

ProAuth supports configuring both mechanisms on the same client application. When both are configured, ProAuth renders the front-channel iframe and sends the back-channel logout notification for the same active session. That can be useful during migration or for clients that need both browser cleanup and server-side session removal.

Register The Client Behavior You Actually Operate

Logout behavior belongs in client application registration, not in a wiki page.

For back-channel logout, configure backchannel_logout_uri on the client application. Use an HTTPS endpoint that ProAuth can reach from its runtime environment, and decide whether backchannel_logout_session_required should be enabled. For interactive browser clients, requiring sid is usually the more precise session-matching model.

For front-channel logout, configure frontchannel_logout_uri. Decide whether frontchannel_logout_session_required should be enabled so the client only receives iframe notifications when iss and sid are available. The endpoint should tolerate repeated calls and should avoid relying on cached responses.

For BFF applications using ProAuth.Bff, the docs describe built-in endpoints for both mechanisms: POST /bff/backchannel-logout and GET /bff/frontchannel-logout. The back-channel endpoint validates the logout token, rejects replayed jti values until token expiry, and removes matching local sessions by sid or by sub for subject-only notifications. That is a good reference shape even when a team implements its own receiver.

Testing should cover the uncomfortable cases, not only the happy path:

  • only clients that participated in the same OP session are notified
  • inactive clients are not notified just because they are registered
  • back-channel receivers validate issuer, audience, signature, lifetime, event, sid or sub, and nonce absence
  • replayed back-channel logout tokens are rejected
  • retryable back-channel failures are retried without treating permanent 4xx responses as transient
  • front-channel endpoints behave sensibly when browser storage or third-party cookies are unavailable
  • local application logout still works even if the user does not complete OP logout

That last point is the practical edge of the distinction. An application can choose to clear its own session before redirecting to the OP, wait for the OP notification, or use a hybrid approach. The right choice depends on the user experience and risk model. What it should not do is assume that every notification path is equally reliable.

A Better Logout Contract

The useful outcome in ProAuth v3 is not that logout becomes instantaneous everywhere. The useful outcome is that session termination coordination becomes explicit.

Registered client applications declare how they can be notified. Back-channel receivers get signed logout notifications over a server-to-server path. Front-channel receivers get browser-based notifications for compatibility and browser-local cleanup. ProAuth scopes notifications to clients that participated in the OP session, uses the session identifier where available, and gives operators a clearer place to test delivery and failure behavior.

That is the logout contract modern OIDC deployments need: precise enough for security teams, practical enough for application teams, and honest about the browser.

For implementation details, start with the ProAuth docs for Back-Channel Logout, Front-Channel Logout, Client Application configuration, and BFF logout endpoints. The release-level summary is in the ProAuth 3.0.0 release notes. For the standards background, read OpenID Connect RP-Initiated Logout 1.0, OpenID Connect Back-Channel Logout 1.0, and OpenID Connect Front-Channel Logout 1.0.