So Far, So Good... SSO WHAT!
Interactive visualizations.
Each demo walks through a complete authentication flow step by step, showing what the user sees alongside the HTTP exchanges happening behind the scenes. Built for engineers, analysts, and Megadeth the band.
OTS authenticates with Google via OAuth 2.0 and OpenID Connect
The simplest common SSO pattern: "Sign in with Google" using the Authorization Code Flow with PKCE. Walk through the redirect to Google, user consent, server-to-server token exchange, and JWT validation.
OTS authenticates directly with Microsoft Entra ID via OpenID Connect
The same authorization code + PKCE dance as the Google demo, pointed at a workforce tenant: tenant-scoped endpoints, admin consent instead of a consent screen, Conditional Access at sign-in, and the tid/oid claims that actually identify an enterprise user.
OTS authenticates directly with Okta via SAML 2.0
Direct SAML integration between application and identity provider. Follow the AuthnRequest, Okta login, signed assertion, and ACS validation in a classic enterprise SSO pattern.
User launches OTS from the Okta dashboard tile
The mirror image of SP-initiated login: Okta pushes an unsolicited signed assertion with no AuthnRequest and no InResponseTo. See what the SP loses, why it matters, and the safer conversion pattern.
One logout click, three sessions, and no guarantee all of them die
The most misunderstood corner of SAML: OTS sends a LogoutRequest, Okta kills its own session, and front-channel propagation to a second app silently fails. Ends with the spec’s own admission -- StatusCode: PartialLogout -- and what to rely on instead.
Okta pushes user lifecycle changes to the app's SCIM API
Provisioning is not authentication: Okta creates, updates, group-pushes, and deactivates accounts in OTS via server-to-server REST -- no end-user browser in the protocol. See the full lifecycle, and why deactivation without session revocation leaves the door open.
Caddy + Logto bridge OIDC↔SAML to Entra
The gateway handles enterprise SSO; the application just receives authenticated requests. Step through every redirect, cookie, and token exchange in the complete flow.
One email-first sign-in page routes each organization to its own IdP
Alice types alice@contoso.com and lands on Entra via OIDC; Bob types bob@acme.com and lands on Okta via SAML. Follow the domain lookup, the per-realm redirects, and the realm-binding checks that keep one tenant from impersonating another.
Planned demos include OIDC back-channel logout and just-in-time provisioning.
The example application is Onetime Secret (OTS) — an open-source tool for sharing sensitive information via self-destructing links. It serves as a realistic stand-in for any web application adding SSO support.