An OIDC back-channel logout ends a user's sessions at one app. It does not revoke the customer's tenant

An OIDC back-channel logout ends a user's sessions at one app. It does not revoke the customer's tenant

The buyer question an MSP hears after an incident call is: “our IdP sent a back-channel logout, so the customer's whole tenant is cut off, right?” The short answer is no. Under OpenID Connect Back-Channel Logout 1.0, the identity provider posts a signed Logout Token to a relying party, and that token names one end-user (issuer plus subject) and/or one session. With no session identifier, the relying party ends all of that user's sessions at that relying party, and nothing more. There is no tenant claim and no “revoke everyone” meaning.

This FAQ answers six questions MSPs ask when a logout signal is mistaken for off-boarding. What does a 200 OK from the logout endpoint prove, and what does it not prove? Why are machine-to-machine integrations out of the logout path entirely? Why does ending the IdP session not automatically end app sessions, as NIST SP 800-63C-4 (26 August 2025) states? Where does a tenant- or policy-scoped revoke signal live, under CAEP over the Shared Signals Framework, and why does that still not replace a per-request authorization check? And why is logout not deprovisioning?

The rule of the piece is simple: tenant off-boarding is an admin and authorization action, never a side effect of a logout. The sources are the OpenID, IETF, NIST and OWASP texts verified on 5 October 2026. There is no token construction and no claim that any Altovar product transmits or receives these logout or shared-signal events.

Is the customer's whole tenant revoked when the IdP sends a back-channel logout? In the buyer's words: “they logged out, so everyone at that customer is gone.” The answer is no. A Back-Channel Logout request is an identity-provider-to-relying-party POST carrying a signed Logout Token, as OIDC Back-Channel Logout 1.0 section 2.4 defines it. The token identifies one end-user by issuer and subject, and/or one session by session ID. That is the radius the standard gives the signal.

When the session ID is absent, the relying party ends all of that user's sessions at that relying party. That is the widest the standard goes. It is still one user and still one app. Ending every browser session Alice has at the ticket portal does not end Bob's sessions at the same portal, and it does not end Alice's sessions at a different portal that never received a Logout Token.

The Logout Token carries no tenant claim and has no “revoke everyone” meaning. A relying party that treats a logout as tenant revocation is inventing behaviour the specification does not define. Tenant revocation, as a set of separate admin acts rather than a product walkthrough, means disabling the tenant record, revoking its grants and client registrations, rotating the credentials it holds, and making the policy decision point deny its requests. Each act has an owner and an audit trail. None of them is a logout.

A brief note on signatures, kept at a high level: the specification requires the Logout Token to be signed and short-lived precisely so a relying party does not act on a forged or replayed logout. This article does not describe how a token is built or checked. The point for the MSP is the radius: one user, one app, not the customer tenant.

The logout endpoint returned 200 OK. Are all of the user's tokens dead? Not necessarily. A 200 OK means the relying party cleared state for the sessions it was told about. It is a receipt from that relying party, not proof that every token everywhere is gone.

Refresh tokens, from Back-Channel Logout section 2.7, follow a narrower rule. Refresh tokens tied to the logged-out session and issued without offline_access SHOULD be revoked; offline-access refresh tokens normally SHOULD NOT be. That is a generic property of the standard. This article does not tie it to any vendor's configuration, and it does not quote idle or lifetime values.

Access tokens tell a different story. A self-contained (JWT) access token stays valid until it expires unless the resource server checks it live through introspection (RFC 7662), or the token is revoked at the authorization server (RFC 7009). RFC 7009 section 3 itself notes that immediate revocation of self-contained access tokens needs extra, non-standardized coordination between authorization server and resource server, or short token lifetimes. A 200 OK on logout is not that coordination.

One introspection guardrail in one sentence: active: true means the token was issued and is not revoked or expired. It says nothing about whether this tenant or this action is allowed. That is a separate question, and this piece does not expand on it. The OWASP Session Management Cheat Sheet adds one more line: logout must invalidate the session on the server side; deleting a browser cookie is not the same thing.

Does logout cut off machine-to-machine integrations? No. Back-Channel Logout ends end-user sessions at relying parties. A machine client that obtains tokens through the client-credentials grant has no user session and no session ID, so a Logout Token cannot target it. The signal has nowhere to land.

The MSP consequence, in plain words: the RMM connector, the billing sync, and the backup agent's API client keep working after every human at the customer has been logged out. That is correct protocol behaviour, and it is exactly why “we logged everyone out” is not an off-boarding record. The humans are gone from the apps that received a Logout Token. The integrations are not humans and did not receive one.

Off-boarding an integration is its own checklist, written as outcomes rather than vendor clicks: disable or rotate the client's credentials, revoke the tokens it already holds, and remove its tenant entitlement at the decision point. Each of those is an admin and authorization act with an owner. None of them is produced by a logout POST.

Does ending the IdP session automatically end app sessions? No. NIST SP 800-63C-4 (Revision 4 final, page dated 26 August 2025) says ending the subscriber's session at the IdP “will not necessarily terminate any sessions that subscriber might have at downstream RPs.” The two sides may pass end-session events to each other if the federation protocol supports it, or through shared signaling. “May” is not “will.”

Back-Channel Logout is one such mechanism, and it is best-effort. The relying party must register a back-channel logout URI, the identity provider must be able to reach it, and the identity provider retries only after errors it believes are recoverable (Back-Channel Logout section 2.5). An app that never registered, or was unreachable when the IdP posted, keeps its session. A firewall rule, a stale URI, or a missing registration is enough to leave a live session behind.

NIST SP 800-63B-4 section 5 adds one sentence of dictionary: sessions end on timeout or explicit logout, and federation behaviour is deferred to 63C. So “the IdP timed out” and “every app logged out” are two different facts. An MSP ticket that conflates them will close the wrong work.

Logging a user out also does not remove tenant membership or roles. NIST SP 800-63C-4 treats terminating a relying-party subscriber account—removing identifiers, authenticators and attributes—as a separate act from ending a session. Membership and roles are provisioning and authorization data; changing them is deprovisioning. The repeatable line is: session end ≠ account termination ≠ tenant off-boarding.

Where does a tenant-scoped revoke live, if not in a Logout Token? The OpenID Shared Signals Framework 1.0 with the Continuous Access Evaluation Profile (CAEP 1.0, both Final) defines session-revoked and token-claims-change events. Their subject can be a complex subject that includes a tenant component. That is the closest a standard gets to a tenant- or policy-scoped revoke message.

It is still a signal: the receiver decides what to do with it. Receiving an event is not the same as having revoked access. A product that ignores the event, delays it, or maps it to a soft warning has not performed the deny. The event is a trigger, not the decision.

Product authorization still has to deny by default and check tenant status and permissions on every request, as the OWASP Authorization Cheat Sheet frames it. A logout or CAEP event is a trigger for that check, not a replacement for it. An MSP that treats “CAEP received” as “access revoked” is skipping the decision point.

This article does not say which products transmit or receive CAEP. Specifically, it does not say Auris does. The article describes the standard only, and it makes no claim that any Altovar product supports CAEP, SSF, or back-channel logout.

This is not a FAQ about PAR, PKCE or passkeys. Those topics concern how a login or authorization request starts. This piece is about what a logout signal ends. Starting a request and ending a session are different jobs, and mixing them produces the wrong ticket.

Nor is it a FAQ about group claims or SCIM. Provisioning and role data appear here only to say that logout does not change them. Membership rows and role grants survive a Logout Token unless a separate admin act removes them.

It is not about DPoP or authenticator binding ceremonies either. Sender constraint and authenticator binding answer different questions from logout radius.

And it is not about short-lived tokens or token TTLs. Those topics concern how long a token lives. This one is about the radius of the logout signal—session or user versus tenant—not about lifetime. A short-lived access token and a Logout Token can both be present in a stack and still leave machine clients and other apps untouched.

This article does not claim that Auris supports back-channel logout, CAEP, or SSF, advertises backchannel_logout_supported, honours a per-client backchannel_logout_uri, or transmits shared-signal events.

The line to repeat: a logout signal ends sessions; revoking a customer tenant is a deliberate admin and authorization decision, checked on every request.