Back-Channel Logout

Back-channel logout lets ProAuth notify relying party applications directly when a ProAuth browser session ends. This is useful for enterprise single sign-out because it does not depend on browser iframes or third-party cookies.

Configure the client application with:

Setting	Description
backchannel_logout_uri	Absolute HTTPS endpoint that accepts logout notifications. The URI must not contain a fragment.
backchannel_logout_session_required	When enabled, ProAuth only sends notifications for this client when a sid is available. New interactive OIDC sessions include a sid.

HTTP back-channel logout URIs are rejected by default. They can be enabled only for non-public clients with the development/test setting BaseServiceSettings:AllowInsecureBackchannelLogoutUris.

Receiver Endpoint

The client endpoint must accept an HTTP POST with content type application/x-www-form-urlencoded. ProAuth sends one form field:

logout_token=<signed JWT>

The logout token is signed with the same signing keys published by the ProAuth JWKS endpoint and uses typ value logout+jwt. Validate the token as a JWT and check:

Claim	Expected value
iss	The ProAuth issuer for the tenant.
aud	The client application ID.
iat and exp	The token is short lived and expires after 2 minutes.
jti	Unique token identifier. Receivers must reject replays until the logout token expires.
events	Contains http://schemas.openid.net/event/backchannel-logout.
sid	Session identifier for the OP browser session when available.
sub	ProAuth subject identifier for the logged-out user.

The logout token never contains a nonce claim.

ProAuth.Bff performs this validation for BFF applications. When back-channel logout is enabled, the BFF must have IDistributedCache registered. The cache is used for logout-token replay protection keyed by issuer, audience, and jti, and should be backed by Redis or another shared provider in multi-instance deployments.

Delivery And Retries

When a user logs out, ProAuth sends one immediate POST to each enabled client application that participated in the same OP session and has a backchannel_logout_uri. Clients from other sessions are not notified.

Responses 200 OK and 204 No Content are treated as successful. Network failures, timeouts, HTTP 408, HTTP 429, and HTTP 5xx responses are retried. HTTP 4xx responses such as 400, 401, and 403 are treated as permanent delivery failures.

Retryable failures are stored in the ProAuth state store and processed by the back-channel logout retry job. The default retry policy uses exponential backoff starting at 60 seconds, capped at 60 minutes, and stops after 6 attempts. In multi-instance deployments, all instances must share the same state store and lock store so the retry queue is durable and only one worker processes due entries at a time.

Troubleshooting

If a client does not receive logout notifications, verify that the client application is enabled, backchannel_logout_uri is configured, and the URI is reachable from the ProAuth runtime. Also verify that TLS certificates are trusted by the ProAuth container.

If retries are not processed, verify that the ProAuth job queue is running and that all instances use the same state store and lock store configuration. Permanent failures are not retried; check the receiving application logs for HTTP 400, 401, or 403 responses.

If a BFF rejects all logout notifications with a replay-protection configuration error, register a distributed cache provider before enabling back-channel logout. In production, avoid per-instance memory caches because they cannot detect replays that arrive at another pod.