Did you know? A person can sign out of an identity provider while an AI agent still holds a working session in a connected application. Clearing a browser tab does not automatically prove that every relying party has invalidated its own session, nor that already-issued API access tokens have been revoked. OpenID Connect back-channel logout addresses a narrower, important problem: an OpenID Provider sends a signed Logout Token directly to a registered Relying Party so the latter can find and clear the corresponding login session without depending on the user’s browser.
To build this reliably, bind logout events to the correct issuer, client, subject or session identifier; verify the cryptographic token and its type; distinguish session-scoped logout from account-wide logout; apply invalidation idempotently; and separately verify what happened when delivery was delayed or a relying party failed. A successful HTTP request is evidence of one protocol step, not proof that every device, long-lived grant or downstream service has stopped accepting authority. Treat missing receipts as uncertainty and use an authorised recovery path.
This is practical identity and agent-system engineering for present-day software. Artificial superintelligence remains hypothetical. The worked example below uses explicitly invented service counts to make the evidence and denominator boundaries clear; no live identity system is claimed to have been modified or tested.
Contents
- The real reader job: end an authorised session without pretending the whole internet logged out
- Three kinds of state that must not be confused
- Registration and discovery decide where the event may go
- What the signed Logout Token actually needs to say
- The difference between one session, all sessions and unrelated grants
- The receiver validation gate before any local state changes
- Worked case: twelve live sessions and three relying parties
- Expiry, delayed delivery and the cost of an uncertain network outcome
- Duplicate events, replay resistance and at-least-once delivery
- Failure modes that turn a legitimate logout into a security incident
- Changed-context exercise: session-specific sign-out from a shared device
- What the standard and a successful implementation do not guarantee
- Frequently asked questions
- Reader pathways and authoritative source notes
The real reader job: end an authorised session without pretending the whole internet logged out
Imagine an assistant connected to a school portal, a messaging service and a document library through a common identity provider. The user signs out centrally after finishing a shared computer session. Each connected application may hold its own cookie, server session, in-memory job and account-level refresh token. The identity provider can end its own session promptly, but it cannot reach into an unrelated application’s memory by wishful thinking. Some coordinated signal is necessary, and the receiving application must know exactly which local state to invalidate.
Back-channel logout is that signal when both sides implement it. In OpenID terminology the identity provider is the OpenID Provider, or OP; each connected application is a Relying Party, or RP. The OP sends an HTTP POST to a previously registered back-channel logout endpoint on the RP. That POST carries a signed JWT called a Logout Token. The token identifies the issuer, the intended client and either a subject, a session ID or both. The RP validates the message before performing its own logout actions.
The OpenID Foundation’s Back-Channel Logout 1.0 specification incorporating errata provides the precise protocol. It differs from front-channel logout because delivery occurs directly between services rather than requiring a browser page to visit each RP. That removes one class of browser-dependence, but creates distributed-delivery, freshness, duplicate-event and local-state questions.
The primary promise is about login-session invalidation at a correctly configured recipient. It does not universally mean that every OAuth access token disappears immediately, that a separately authorised offline grant is cancelled, that data cached on a disconnected device is erased, or that every downstream job stops. These are different authority surfaces. A truthful service reports which ones it actually controls and verifies.
For an agent, the security boundary matters as much as the transport. The assistant must not independently decide that an untrusted webpage or chat sentence is a valid instruction to log everyone out. The signed event comes from the registered OP through the authorised validation path; the agent may help observe and reconcile its effects but cannot promote arbitrary text into a privileged logout event.
Three kinds of state that must not be confused
Start by drawing the OP session, the RP’s local session and the API credential separately. The OP session concerns authentication at the identity service. The RP local session often appears as a cookie-backed or server-side login state authorising access to the application. OAuth access and refresh tokens may allow independent API calls under grants that have their own expiry, revocation and offline-access rules. They are connected in a user journey, not identical in lifetime or ownership.
A back-channel Logout Token tells a receiving RP to clear the sessions covered by the asserted identity scope. If the RP uses a purely stateless signed browser cookie with no revocation lookup, receiving the event is not enough: a previously issued cookie might remain cryptographically valid until its expiry. The application needs a session-revocation mechanism, such as a denylist, session version or centrally checked validity. Choosing that mechanism is part of the RP design.
Likewise, an agent with a cached access token may be able to call another service even after a browser session ended if that service does not validate a revoked grant or the token is still within its allowed lifetime. The RP should not claim the wider token has vanished merely because it deleted a web session. Test these paths independently and ensure logout decisions match the registered protocol’s scope.
A user may have multiple devices and applications. The OP may know a subject identifier for the account and an opaque session identifier for one sign-in. The difference determines whether the receiving RP is meant to invalidate every local session associated with that subject and issuer or only one related session. A logout record that stores only the user-friendly email address loses essential context and can affect the wrong identity after addresses change.
Keep an audit of the state transitions, not a single Boolean called logged_out. Useful states include the OP logout event generated, destination selected, request attempted, RP validation result, targeted local sessions found, those sessions invalidated, and follow-up checks of whether subsequent requests are rejected. If one part cannot be observed, label it unknown. That honesty is crucial when designing reliable agents.
Registration and discovery decide where the event may go
An OP can advertise its support for back-channel logout through discovery metadata. The specification defines fields including backchannel_logout_supported and backchannel_logout_session_supported; an RP can register a backchannel_logout_uri and may indicate whether it requires a session identifier. Read each supported value rather than assuming every product advertising ‘single sign-on’ implements the same logout mode.
The back-channel endpoint is an application-controlled HTTPS service endpoint selected through trusted registration, not a URL accepted from a random incoming request. The published specification describes its URI rules and allows constrained situations with HTTP for confidential clients, but current production designs should normally use authenticated, protected HTTPS transport and origin control. Do not invent a fallback destination because a legitimate RP is temporarily offline.
Identifiers must be stable in the relevant namespace. An OP issuer identifier is not an informal service nickname. A client audience is not the user’s email. The RP must maintain a reliable mapping from the issuer, subject and any session identifier to its own local sessions. An OP may use pairwise subject identifiers; joining accounts by unverified display names can break the isolation the protocol expects.
When the RP has multiple tenants or regions, map the intended issuer and registered client into the correct tenant before invalidating sessions. A malformed token with a genuine signature from a different issuer must not gain authority over a local account with an overlapping subject string. Use the configured trust record as the starting point, not a tenant value copied from untrusted token text without verification.
Registration changes have their own lifecycle. If the back-channel endpoint changes during a deployment, the OP might still send to an old URL. Avoid silently redirecting sensitive POST bodies to unexpected hosts. Deploy a planned overlap or re-register the endpoint, validate the new path, and retire the old path deliberately. A rollout checklist should include both the sender’s registered destination and the receiving application’s route.
What the signed Logout Token actually needs to say
The Logout Token is a JSON Web Token with claims whose meanings are defined by the OIDC logout specification. In the version incorporating errata, iss identifies the issuing OP, aud names the intended RP audience, iat records issuance time, exp gives expiry, jti supplies a token identifier, and events identifies the back-channel logout event. The token must identify at least one of sub or sid. These are technical claims with different purposes; simply finding a field called token or logout in JSON is not validation.
The events claim must contain the exact back-channel logout event member, whose value is a JSON object. An arbitrary application event or an ordinary ID Token is not an acceptable substitute. In particular the Logout Token must not contain a nonce claim. This restriction helps prevent confusion between logout credentials and authentication tokens. The specification also recommends the explicit JWT type logout+jwt; implementers should consult the precise profile and version supported by their OP.
A Logout Token must be signed. The RP must check the signature against properly associated OP key material and accepted algorithms, not merely decode the JWT and trust its readable claims. Reject the unsecured alg=none case. Validate the issuer against the configured provider, the audience against the registered client, and the timing and required fields according to the specification. Expiry matters even when the transport call arrived over TLS.
The adjacent eduKateSG article Agent JWKS Key Rotation explains why the key identifier and algorithm choice cannot be allowed to override trusted verification policy. A valid-looking kid should select among authorised issuer keys, not enable arbitrary key fetching or an attacker-provided verification rule.
Some deployments encrypt Logout Tokens, in which case permitted encryption settings and validation requirements must also be applied. Encryption changes confidentiality and processing steps; it is not a replacement for validating a trusted sender or checking the event’s meaning. Keep the JOSE processing policy narrow and auditable.
The difference between one session, all sessions and unrelated grants
The sub claim represents the end user within the issuer’s identity namespace. The sid claim represents a particular session associated with an end user at the OP and RP context. Under the OIDC specification, a Logout Token without sid is intended to log out all sessions at the RP for the identified issuer and subject. A token with sid supports a narrower session-targeted operation, subject to the RP’s binding and any additional claims.
Suppose a person uses a tablet and a desktop browser. They may have two RP sessions after authenticating through the same issuer. If a valid sid-scoped logout refers only to the desktop sign-in, deleting the tablet’s independent session may be an overbroad disruption. If the protocol legitimately signals account-wide logout through issuer and subject without sid, deleting only the last browser cookie may leave an uninvited active session. The scope is a security rule, not a stylistic preference.
The RP should maintain local session records with issuer, subject, session identifier when available, account or tenant identifier, and current validity. The lookup should match the token’s verified scope. A missing sid is not permission to invalidate every account from the issuer. It requires a valid subject; the matching issuer and intended audience remain essential.
Offline grants make the boundary more nuanced. The back-channel logout specification recommends revoking refresh tokens for sessions without offline_access, while generally not revoking refresh tokens granted with offline_access. That is not equivalent to saying that all refresh tokens are automatically revoked. A service may have additional policy obligations, but it should state and test them separately.
When a previously accepted user interaction is in flight as the logout event arrives, the application may need to stop the job or recheck authority before an irreversible action. That is a workflow and revocation policy decision. The agent must not assume that deleting one session automatically compensates an external email, file update or payment. The correct response may be to pause and escalate.
The receiver validation gate before any local state changes
A safe RP endpoint receives the POST body as defined by the protocol and extracts the logout_token parameter. Before mutating a session, it validates the JWT, including any negotiated decryption, issuer, signature, allowed algorithm, audience, relevant time fields, required event structure and permitted identity claims. If validation fails, the specification instructs rejection rather than partial logout. Do not use unsigned request metadata as a fallback identity.
Token type confusion is a concrete threat. A valid ID Token used to sign a user in must not automatically be accepted as a Logout Token merely because its issuer and signature check out. The event marker, nonce prohibition, type expectations and identity claims are part of the meaning. An agent reading a decoded token does not have enough evidence to conclude the message is authorised.
Replay is another boundary. The jti identifier enables a receiver to recognise a recently processed token. The specification makes replay checking optional, but a consequential system can use a bounded per-issuer replay cache and idempotent state transitions to reduce duplicate work and abuse. Define the retention period and capacity; never pretend one cache entry guarantees protection from all attacks or clocks outside its expected window.
Validation must remain specific to the intended client. A Logout Token issued for application A is not authority to log someone out of application B merely because both trust the same identity provider. Match the aud claim to the RP client ID and map the issuer into its configured trust record. Multi-tenant implementations must avoid a shared lookup that confuses similar subject strings.
Only after validation should the receiver determine which sessions exist and invalidate the intended records. If the user is already logged out at this RP, successful idempotent completion is the expected outcome rather than an error to be retried indefinitely. A final HTTP response is one receipt; applications still need business-level observability of session invalidation.
Worked case: twelve live sessions and three relying parties
Here is a fictional example with fully specified denominators. A single identity provider knows that one account has twelve active RP sessions distributed across three applications: five sessions at library A, four at classroom B and three at messaging C. The OP initiates a subject-wide logout intended to terminate all twelve sessions. The intended human account count is one, the RP count is three and the local session count is twelve. Those are different units.
The OP sends one signed Logout Token per registered RP endpoint, with the same account intent but each RP’s appropriate audience. Library A validates the token, invalidates its five sessions and returns a successful response. Classroom B initially returns a temporary error; after a bounded retry it validates and invalidates four sessions. Messaging C returns a positive HTTP response, but an independent post-event check still finds all three previously valid local sessions active because the receiver incorrectly updated a non-authoritative cache.
The sender observed successful request responses from two destinations and a recovered attempt at the third. Counting last request responses alone could misleadingly produce 3/3 successes. The verified session outcome is only (5+4)/12 = 9/12 = 75% invalidated. The three sessions at C remain active and represent 3/12 = 25% unverified or failed according to the actual readback. The correct security report must prioritise that denominator over the transport dashboard.
Now suppose an engineer checks again and determines that C’s source-of-truth session table has been updated, but one browser cookie still authorises a stale session because the application only validates signatures locally. That would mean an invalidation record exists but the session-enforcement mechanism is incomplete. The problem is not solved by resending a token until the endpoint says success. The RP needs a validity check that all access paths respect.
This example deliberately labels its data as invented; no real OP, RP or client was queried. Its arithmetic illustrates a principle: request success rates, account-level reach and session-level invalidation are not interchangeable. When a user says ‘log me out everywhere’, the only adequate completion statement is bounded by what the services and tests actually prove.
Expiry, delayed delivery and the cost of an uncertain network outcome
Distributed systems fail between steps. The OP can send a token, the RP can process it, and the response can be lost. A retry sent without regard to the original token may create duplicate work. The logout operation should be idempotent for the target session state, and the sender should reconcile observed status before retrying when such evidence exists. A second copy of the same authorised logout event should not restore or broaden access.
The current incorporated-errata specification includes an exp claim and provides security guidance for short-lived tokens, encouraging short expiry windows. That limits replay exposure, but does not replace event-level checks. If an RP receives an expired token long after a network outage, it should not silently waive the validation rule merely to clear its queue. A separately authenticated recovery mechanism may be necessary.
Time fields depend on the issuer’s clock and the receiver’s allowance for reasonable clock skew under the agreed protocol. Huge clock-skew tolerances undermine freshness controls; zero tolerance can reject honest requests from imperfectly synchronised systems. Record server-observed receipt time separately from the signed issuance and expiry times. Do not invent a timestamp based on the display time in an agent chat transcript.
A timeout during delivery is not definitive proof that the RP did nothing. The RP may have invalidated the session before the network connection failed. First check the state when authorised, then retry with a bounded policy. The earlier guide Agent Push Notifications uses a similar boundary: transport acceptance cannot be promoted into verified human or business outcomes.
An OP may use parallel delivery to reduce total latency, but parallel sends require independent per-RP outcomes. A failed endpoint should not erase evidence that another endpoint completed. The audit needs stable event identifiers, a destination map and a deadline for escalation. A user-facing success message should never be more certain than the supporting state.
Duplicate events, replay resistance and at-least-once delivery
An implementation should expect the same Logout Token to arrive more than once when a sender legitimately retries a recoverable delivery failure. Idempotency means that invalidating an already-invalidated session produces the correct final state without unintended side effects, not that every duplicate is accepted without validation. Signature, audience, issuer, claim structure and expiry checks still apply on every event.
If a replay cache records jti, use an issuer-qualified key rather than assuming two providers cannot issue the same identifier. Decide whether a duplicate should receive a successful already-processed response or a protocol-appropriate error according to the implementation contract. Either way, it must not cause a second unrelated mutation. Unknown or very old events should be handled consistently with expiry and replay policies.
The receiver’s database transaction may need to invalidate several local sessions. A partial commit is possible if one of those operations fails after others succeed. The implementation should either make the state transition atomic where feasible or record a durable work item with a recoverable cursor. Do not send a global success response while known targeted sessions remain valid.
Some services cache authorisation state on multiple nodes. Updating one in-memory process does not automatically invalidate sessions served by other replicas. Use the service’s chosen consistency strategy, such as a shared session store, revocation version or cache invalidation event with verified propagation. The correct approach depends on how requests actually authenticate.
Once invalidation is durable, downstream in-flight jobs may still need checks. A long-running agent workflow should re-evaluate whether its authorisation is active before a consequential write. Logout alone is not a universal cancellation transaction. This is why identity controls and safe workflow transitions must be specified and tested as related but distinct components.
Failure modes that turn a legitimate logout into a security incident
Failure one: a receiver decodes a JWT without checking its signature, then uses the readable sub claim to log out someone else’s account. Repair: verify the signed token against the configured issuer and permitted algorithm before any state mutation. Failure two: a token for one client is accepted by another. Repair: validate the aud claim and bind trust by issuer, client and tenant.
Failure three: a sid-scoped event invalidates every session from the same email address. Repair: use verified identifiers and the token’s actual scope. Failure four: subject-wide logout removes only the current browser cookie. Repair: enumerate all matching local sessions under the configured identity namespace, and make enforcement consult revoked state.
Failure five: the RP accepts an ordinary authentication ID Token as a Logout Token. Repair: enforce the logout events structure, nonce prohibition and appropriate JWT type and profile rules. Failure six: the service treats a network timeout as proof no write occurred and spins up unbounded new event IDs. Repair: reconcile the original event and use bounded idempotent retries.
Failure seven: a stale application node accepts a session after the database marks it revoked. Repair: test revocation propagation across all nodes and fail safely if the authoritative check is unavailable in high-risk circumstances. Failure eight: the organisation assumes central logout automatically revokes independent offline API grants. Repair: map each grant’s lifecycle and report which authority surfaces remain.
Failure nine: a security dashboard uses successful POST count as the number of sessions logged out. Repair: report number of targeted local sessions and independently verified invalidations with the denominator. Failure ten: an RP accepts a replayed token long after its validity window because it has a special-case debugging switch. Repair: retain test-only exceptions outside production and require a properly authorised recovery procedure.
These are distinct faults. A good incident report identifies the last verified boundary, whether the problem was validation, delivery, state mapping or enforcement, and what evidence confirmed repair. Generic claims such as ‘the logout service is green’ are not enough.
Changed-context exercise: session-specific sign-out from a shared device
Now change the scenario. A student has three sessions at one application: a shared family tablet, a private laptop and a school browser. The OP issues a valid Logout Token containing sid for only the shared tablet session, with the correct issuer and audience. The application locates exactly one matching local RP session and marks it invalid. The other two remain active under the stated session-specific intent. Is that a failure of global logout? No: the event did not request global logout.
Suppose the shared tablet’s local session is recorded as invalid but its stale signed cookie still passes a stateless check. The user can still open protected data. The result is a security failure despite correct token validation and accurate session selection. The repair belongs in the application access-enforcement path: enforce current session validity for every protected request, not just during logout processing.
Imagine a later subject-wide token without sid arrives for that account. Its intended scope now includes the remaining two sessions; all three should be unusable after the new event completes. The receiving service should distinguish the initial one-session operation from the later all-session operation in its log. A count of one plus two distinct invalidations equals three, but only if the same sessions are not counted twice.
The exercise changes a single key constraint and therefore changes the correct result. The lesson for an agent is to preserve scope and chronology: user identity, issuer, session, current status and business authority. It must not widen a narrow command merely because ‘logout everywhere’ sounds more secure.
If a different application is also involved, the OP must deliver the appropriately targeted event to that application’s registered endpoint. The RP cannot invent privileges to revoke unrelated accounts simply by observing the student’s device labels. Verification remains per destination, per scope and per actual protected action.
What the standard and a successful implementation do not guarantee
Back-channel logout is a coordination protocol, not a magical global kill switch. Only participating, correctly configured relying parties receive and understand its events. Native applications, browser sessions and API gateways can have different enforcement models. The OP may not be able to prove from a successful POST that a receiving application’s every authorisation path is now closed.
Different logout modes exist, including front-channel and RP-initiated logout, and they answer different initiation and delivery questions. Conflating them can lead to false expectations about what a single browser action achieves. Read the relevant protocol documentation for the exact issuer and RP product being deployed rather than inferring capability from a marketing term such as single sign-on.
Session invalidation and OAuth token revocation also require separate analysis. Offline access may remain valid under the policy expressed by the OIDC standard. An externally published signed access token can remain valid at a resource server until expiry unless that system has a revocation check. A secure application should make these remaining authorities visible in its account and incident controls.
The protocol does not choose whether a cancelled session should cancel a pending financial transaction or delete a user’s documents. Those are application decisions involving consent, audit and often legal or safety obligations. An AI agent must not improvise irreversible compensation merely because a logout event arrived.
Finally, cryptographic validation requires sound operational key management, time handling, secure transport and correct configuration. No amount of polished explanation replaces independent testing. This guide is for contemporary system design and makes no assertion that artificial superintelligence has been achieved.
Frequently asked questions
Does OIDC back-channel logout require a browser? No. It sends a signed Logout Token from the OpenID Provider directly to the Relying Party’s registered endpoint. That is its central distinction from browser-mediated front-channel logout.
Does a successful back-channel HTTP response mean every API token is revoked? No. Local session invalidation and access or refresh token policy can differ. Check the grant and resource-server rules separately.
What do sub and sid mean? Sub identifies an end user within an issuer’s namespace; sid identifies a session. A valid event without sid is intended to invalidate the relevant subject’s RP sessions, while a session-specific event can identify a narrower target.
May an application trust the JWT after decoding it? No. It must validate signature and configured issuer and audience plus the specific logout token requirements before changing state.
Why must the events claim be checked? It identifies this JWT as an intended back-channel logout event. Without purpose checking, tokens issued for another function could be confused with logout instructions.
Do retries always cause trouble? No, provided the receiver is idempotent and every attempt is properly validated. The danger comes from uncontrolled retries, confused scopes and invented success reports.
What should happen if the user’s RP session is already absent? The specification treats logout of an already-logged-out user as successful. Do not re-create a session to make a logout operation visible.
How should an agent report incomplete logout? It should name the destinations and session counts it could verify, disclose pending or unknown outcomes and provide the approved next step rather than claiming an unqualified global success.
Can the system log a person out of someone else’s app? Not automatically. Each relying party must participate and authenticate the event under its registered trust configuration.
Why is nonce absent? OIDC forbids nonce in a Logout Token to reduce cross-purpose confusion with authentication ID Tokens. This is a protocol-validation requirement, not an optional display preference.
Reader pathways and authoritative source notes
If you implement a Relying Party, start with the registered issuer, client and logout URI, then write failing tests for wrong issuer, wrong audience, expired token, invalid signature, missing sub and sid, unexpected nonce, wrong event type, duplicate jti and a valid session-specific logout. Test all local application nodes for enforcement after invalidation.
If you operate the identity provider, track recipient registrations and maintain a destination-specific ledger of delivery attempts, error classes and relevant deadlines. Successful requests should not be equated with verified elimination of all app sessions. If a recipient is offline, maintain the policy’s approved recovery and communication process without inventing alternate endpoints.
If you audit an AI agent integration, ask whether it still holds an API token or workflow authority after logout, how that token is bound to the user and tenant, and when a privileged write rechecks access. Test one session and all sessions as separate scenarios. Avoid collecting more personal login details in logs than necessary.
Official primary documents: OpenID Connect Back-Channel Logout 1.0 incorporating errata, the September 2022 final version, and RFC 8725 JWT Best Current Practices. Read the version and permitted claims precisely, especially where the incorporated-errata text clarifies expiration.
For the wider system-design context, see the already published JWKS rotation and JWT verification guide, the notification delivery uncertainty guide, and the How Super Intelligence Works overview. The worked numbers here are teaching examples, not reported deployment outcomes.