A user selects “Sign out” in one application. Another application still opens without a prompt.

That result may reflect an incomplete logout flow. It may also reflect a different session that your product never intended to end.

Single sign-on does not create a single universal session. Design logout around the state each participant controls.

Inventory four separate kinds of state

An OpenID Connect relying party is an application that accepts authentication from an identity provider.

That application can maintain its own session after the provider completes authentication. Tokens can have additional lifetimes.

State	Typical owner	Question for your design
Application session	Individual application	Which server-side record must end?
Identity-provider session	Identity provider	Should another login require interaction?
Refresh token	Client and authorization server	Can the client obtain another access token?
Access token	Client and resource server	Will a protected API still accept it?

Use this inventory before choosing a logout button label.

“Sign out here” and “Sign out of all applications” promise different results. Implement and test the result that the label describes.

Separate local logout from provider logout

Local logout ends the application's own session. It should not depend on reaching the provider before removing local access.

RP-Initiated Logout defines how an application can request provider logout.

The provider may use an ID-token hint to identify the relevant context. Post-logout redirects require the specified validation and registration rules.

Do not accept an arbitrary return address from a query parameter. Maintain the permitted redirect configuration for the application.

A successful redirect is evidence of navigation. It is not evidence that every downstream application's session has ended.

Use back-channel logout for server notification

OpenID Connect Back-Channel Logout defines direct provider-to-application logout notifications.

The application validates a signed Logout Token. Relevant checks include the issuer, audience, signature, event, and session or subject identification.

A Logout Token is not an ID token. Do not send it through a generic sign-in path.

Its events claim identifies the logout event. The token must contain a subject or session identifier, and must not contain a nonce claim.

After validation, locate the matching local sessions and end them. The endpoint must not depend on the browser supplying its application cookie.

User --> Application A: sign out
Application A --> local session store: end session
Application A --> Identity provider: request provider logout
Identity provider --> Application B: signed logout notification
Application B --> local session store: end matching session

Preserve the session mapping

Suppose one person has two browser sessions. Your service needs to distinguish ending one session from ending every session for that person.

Store the provider's issuer and subject with the local identity mapping. Store the provider session identifier when the flow supplies one.

Never join records through an email address alone. The issuer is part of the identity boundary.

Use the session identifier's scope correctly. Do not let a notification from one configured provider terminate an unrelated provider's sessions.

Define idempotent processing. Repeated delivery should not turn an already-ended session into an error that requires manual intervention.

Decide what happens to tokens

OAuth token revocation defines an endpoint for revoking tokens and describes related grant effects.

Your logout design still needs to state which tokens it revokes. Background access may have a different contract from an interactive browser session.

A resource server that validates a self-contained token locally may continue accepting it until expiry without additional revocation checks.

If immediate denial matters, design an online state check or another supported revocation mechanism. Document the availability and latency trade-off.

An access token remains subject to audience and scope checks. Ending a browser cookie does not replace those checks.

Read the refresh-token rotation guide to separate replay handling from deliberate session termination.

Model partial failure honestly

A distributed logout can encounter a timeout after local access has already ended.

Do not restore the local session because a remote logout request failed. Record the remaining work without retaining unnecessary credentials.

If an application notification endpoint is unreachable, define retry ownership and an operational alert. Confirm the provider's actual delivery behaviour.

Test stale tabs, browser navigation, and a protected API request separately. A cached screen is not the same as a successful authorized request.

A helpful product message states what completed. Avoid promising immediate global logout when the system cannot establish that result.

Test the distributed state transition

Download the logout test matrix. Record expected timing rather than assuming every effect is immediate.

Scenario	Verification
Local session ends	Next protected application request fails
Provider logout completes	Next authorization follows the intended interaction policy
Valid back-channel notification arrives	Only matching sessions end
Notification has the wrong audience	No session changes
Notification is delivered twice	Result remains correct
Application B is unreachable	Failure is observable; recovery ownership is clear
Refresh token is revoked	A later refresh request fails
Old access token reaches the API	Result matches the documented token-revocation policy

Use synthetic users in two applications. Capture server decisions rather than relying only on what the browser displays.

The enterprise SSO checklist covers domain discovery and tenant boundaries that surround this flow.

Review your logout contract with NamoID

The NamoID team can help review customer authentication, session handling, and integration boundaries.

Contact our engineers in Slack for an early response. Bring your application diagram and the exact meaning of “sign out” in your product.

This protocol guide is not a claim that every logout mechanism is enabled for every NamoID deployment. Confirm the supported integration path before relying on it.

Related posts