OAuth 2.0 and JWT Explained: What Really Happens When You Click "Sign In"

Part 18 of 19 · ~3 min

Single Sign-On and Federated Identity

Everything this reference has walked through so far has centered on one app — Tasklight — trusting one identity provider — Kestrel. Single Sign-On is what happens when that same relationship gets copied across several apps at once, all pointed at the same provider: Priya authenticates with Kestrel a single time, and every app in that set treats her as already logged in from then on, with no separate password prompt anywhere along the way. Nothing about the mechanics changes — it's the identical authorization-code-and-token dance from earlier chapters, just running once per app instead of once, period.

Kestrel, as it turns out, isn't exclusive to Tasklight at all. Priya's company also runs a time-tracking tool and an internal wiki on the same identity provider, each one its own independent OAuth/OIDC client with its own client_id, all three trusting the identical Authorization Server. That's federated identity: instead of Tasklight, the time tracker, and the wiki each maintaining their own idea of who Priya is and whether her password still works, all three defer that entire question to Kestrel. The payoff shows up the day someone needs to act fast — disable Priya's account once, in Kestrel's admin panel, and all three apps lose her access in the same instant, rather than someone working through a checklist of every tool she ever touched.

There's a piece of this that most integrations, Tasklight's included until it was pointed out, quietly skip: logout does not automatically propagate the same way login does. Priya clicking "log out" on Tasklight only ever destroyed Tasklight's own session cookie — it had no effect whatsoever on Kestrel's own session, which stayed alive in her browser. The next time she opened the time-tracking tool, it silently re-authenticated her against that still-live Kestrel session with no prompt at all, which is exactly the behavior SSO promises and exactly the surprise Priya isn't expecting from a button she just clicked labeled "log out." A handful of OIDC providers, Kestrel included, support RP-initiated logout: a request that ends Kestrel's own session, not just the calling app's, and — where a provider supports back-channel logout — a server-to-server signal that tells every federated app to end its own session too, without relying on Priya's browser to visit each one. Mechanically, that signal is one more thing this reference has already covered in full: Kestrel sends each app a logout token, which is nothing more exotic than another signed JWT, with its own iss, sub, and aud, verified with the exact same five checks from the validation chapter earlier. The only genuinely new part is the claim it carries in place of the usual ones — events naming this as a back-channel logout, not a login — everything around it is the same signature, the same audience check, the same issuer trust. It's worth checking whether it's actually wired up, because "log out" quietly meaning "log out of one app" is the kind of gap that looks fine in a demo and turns into a real problem on a shared or public machine.