What is SSO?
A new teammate sits down, opens a laptop, and starts the morning ritual: email, chat, HR, code repo, ticketing. Every tool asks for a password. Every tool adds friction. Then someone asks, "Why does this feel like ten doors with ten keys?" That question is where Single Sign-On begins.
SSO is a promise, not a product. The promise is simple: sign in once, and let trusted apps accept that decision without asking again. The trusted decision comes from an Identity Provider (IdP). The apps that accept it are Service Providers (SPs) or clients. The story is about how the IdP and those apps pass trust between them.
The Common Cast
IdP is the place that verifies who you are. SP/Client is the app you want to use. The browser is the messenger that carries the proof back and forth.
Act I: SAML, the Formal Messenger
SAML arrives dressed for a formal event. It carries a sealed envelope: a signed XML assertion. The user goes to the IdP, proves who they are, and receives that envelope. The browser delivers it to the SP, and the SP checks the seal. If the seal is valid and the message is meant for that SP, the door opens.
What the Envelope Says
Inside are the details the SP needs to trust the decision: who the user is (NameID), optional attributes, and timing rules like NotBefore and NotOnOrAfter.
Why SAML Still Wins Rooms
SAML is the veteran in enterprise halls. It fits older systems, long-established vendor ecosystems, and enterprise IdPs. It is reliable and precise, but it is ceremonial. When it fails, the failure is often in the fine print: clock skew, audience mismatch, or a tiny metadata detail.
Act II: OIDC, the Modern Traveler
OIDC travels lighter. It rides on OAuth 2.0 and carries JSON Web Tokens (JWTs). Instead of a sealed letter, it presents a passport: an ID token that says who you are, plus an access token that grants permission to call APIs. The client validates the passport and opens the door.
The Token Exchange
The browser is sent to the IdP with a request. The IdP verifies the user and returns a short-lived authorization code. The client trades that code for tokens, checks their signatures, and then starts the session.
Why OIDC Feels Modern
OIDC speaks JSON, loves APIs, and fits mobile and single-page apps. It is compact, developer-friendly, and fast to integrate. It still depends on signatures and strict validation, but the experience is lightweight and practical.
The Difference, Told as a Choice
Imagine you are building a doorway between two buildings. SAML is a formal messenger with a sealed letter. You inspect the seal, read the note, and open the door. OIDC is a traveler with a passport. You inspect the passport, verify the stamps, and let them in. Both are trustworthy when verified correctly. The difference is the packaging and the ecosystem they come from.
When People Choose Each
- SAML is common for enterprise integrations, older apps, and vendor ecosystems.
- OIDC is common for modern web apps, APIs, mobile, and cloud-native services.
The Moral of the Story
SSO is trust made portable. SAML and OIDC are two different ways to carry it across a boundary. One arrives with a sealed letter, the other with a passport. Pick the messenger that matches your journey, and the parade of logins becomes a single, confident step.