Free & open · no paywall, ever

IntegrAuth Academy

Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.

20 tracks 241 lessons 242 hands-on labs 230+ diagrams 100% free

English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.

How?
  • Chrome on phone: ⋮ menu → Translate
  • Chrome on computer: right-click → Translate to …
  • Edge: the translate icon in the address bar
Identity & API Security Track 5 · Protocols & Federation
0/166 lessons read
PROTOCOLS & FEDERATION · LESSON 3

Signing out across apps

Maya taps "Sign out" in the expense app. She thinks she is signed out of everything. With single sign-on, that is rarely true. Your goal: know every session and token a full sign-out must end.

Key points
  • One login starts an IdP session, app sessions and tokens.
  • A local logout ends only the app's own session.
  • The app asks the IdP to end its session. The IdP then tells the other apps.
  • Back-channel logout is server to server. It is more reliable than front-channel.
  • A signed-out user's access token can still work until it expires.

One login, three things to end

When Maya signs in with single sign-on, three things start. The identity provider (IdP) keeps a session of its own. Each app keeps its own session too. And an app may hold tokens for calling APIs. "Sign out" must reach all three. The sessions lesson shows the cookies.

Think of it like…

a college campus. The main office lists you as inside. The library, lab and canteen each keep their own sheet. You leave through the library, and only the library crosses you out. A full sign-out means the office tells every department.

A local logout is not enough

The simplest sign-out is a local logout. The app deletes its own session and cookie. The IdP session is still alive. When Maya opens the app again, the IdP signs her straight back in.

Step 1: ask the IdP to end its session

The app is the relying party (RP). In RP-initiated logout, it sends the browser to the IdP's logout address. That address is the field end_session_endpoint in the IdP's public settings file (the discovery document, see federation trust). The app adds two parameters:

ParameterWhat it is for
id_token_hintThe ID token from login. It tells the IdP which session to end.
post_logout_redirect_uriWhere to send Maya afterward. The app must register it first. The IdP redirects only if it matches a registered address exactly.
Watch out

An open redirect turns a logout link into a trap. If the IdP accepted any address, an attacker could land Maya on a fake login page. So the match must be exact.

Step 2: tell the other apps

Ending the IdP session does not end App B's session. The IdP must tell each app, in one of two ways. Then it sends Maya to the post_logout_redirect_uri.

🖼️ Front-channel logout

The IdP shows a page with a hidden iframe for each app. Each frame loads the app's frontchannel_logout_uri. Maya's browser must stay on that page. Browsers that block third-party cookies can stop the frame from reaching the session.

📡 Back-channel logout

The IdP sends an HTTP POST with a signed logout token to each app's backchannel_logout_uri. It goes server to server, with no browser. It works even if Maya closes her browser. The app maps the sid to its own sessions.

In the login lesson, the front channel runs through the browser. The back channel is private, and for logout it is more reliable.

IdPSSO sessionApp AMaya taps Sign outApp Bweb appApp Cserver app1 · end_session +id_token_hint2a · front-channel(can fail)2b · back-channel:POST logout_tokenRefresh tokenrevoke it (RFC 7009) ✓ can be endedAccess token (JWT)✗ works until it expiressessions end by message · tokens end by revoking or by waiting
Figure — One sign-out, many things to end. App A asks the IdP to end its session. The IdP then tells App B through the browser (can fail) and App C through a private server call. Tokens are a separate job.

Tokens can outlive the sessions

Ending sessions does not cancel tokens. A refresh token lasts a long time, so the app should cancel it. It sends the token to the revocation endpoint (RFC 7009). The server answers 200, even when the token was already invalid.

The hard case is an access token that is a JWT. The API checks its signature and expiry on its own. It never calls the IdP. So a copied token keeps working until it expires. Plan for it:

⏱️ Keep it short

A 5-minute token is a 5-minute risk.

🚧 Check a cut-off

The API refuses any token issued before the cut-off time. See stolen-token defenses.

📣 Listen for signals

An IdP can send a CAEP "session revoked" event over Shared Signals. See CAEP and Shared Signals.

"Sign out everywhere"

A real "sign out everywhere" button does four jobs. It ends the IdP session, sends back-channel logout to every app, revokes the refresh tokens, and cuts off or expires the access tokens.

Why it matters

A sign-out that leaves one session alive is worse than none. The user believes it worked.

Go deeper: What is inside a logout token

A logout token is a signed JWT. It must never be usable as an ID token. It carries these claims:

  • iss, aud, iat, exp and jti: the IdP, the receiving app, the times, and a unique id.
  • events: the marker http://schemas.openid.net/event/backchannel-logout, with an empty object as its value.
  • sub, sid, or both. The sid names one session. So App B ends her laptop session and not her phone session.
  • Never a nonce. That is how an app can tell it from an ID token.

The app checks the signature and these claims, as it does for an ID token. Then it ends the session. It answers 200 when done and 400 when the token is bad.

Go deeper: more parameters, SAML sign-out, offline tokens and specs

The app may also send state and client_id to the logout address. The IdP may ask Maya to confirm. A front-channel frame can also get iss and sid if the app asked for them. The spec itself warns about third-party cookie blocking.

If the server supports it, revoking a refresh token also cancels the access tokens from the same grant. For a JWT access token, RFC 7009 says that cancelling it at once needs extra messages between servers, which the standard does not define.

The older standard SAML has its own sign-out, called SAML Single Logout. The app sends a LogoutRequest to the IdP. The IdP sends one to each other app and collects each LogoutResponse. The messages usually pass through the browser, one app after another. If one app does not answer, the chain can break. OIDC back-channel avoids the chain: the IdP calls every app on its own.

The OpenID back-channel spec gives advice on refresh tokens. Tokens issued without offline_access should be revoked at logout. Tokens issued with offline_access normally should not, because they are meant for "remember this device". For a real "sign out everywhere", revoke those too, on purpose.

Back-channel logout has limits. The IdP must reach the app's server, so an app behind a firewall cannot use it with a public IdP. The app must end its own session, because it shares no cookies with the IdP.

Status as of October 2026: RP-Initiated Logout 1.0 and Front-Channel Logout 1.0 are Final (September 2022). Back-Channel Logout 1.0 is Final, with errata set 1 (December 2023). The typ header logout+jwt is recommended, not required.

Now play it. The lab runs one full sign-out, breaks it four ways, then lets you build your own to end all six things.

🧪 Interactive lab — enable JavaScript to play with this one.

🧪 Try it free

Grade your issuer's logout and revocation setup with Logout Check.