The first time I wired up single sign-on for a product, I assumed there would be one standard way to do it. There are two. They solve the same problem, they were born a decade apart, and they look nothing alike under the hood. If you have ever read a vendor page that lists "SAML and OIDC" as if they were interchangeable features, this post is the explanation that page skipped. Both let a person log in to an app using an account they already have somewhere else. What differs is the format of the message, the plumbing that carries it, and the world each one grew up in.
I will keep the acronyms honest. SAML is the Security Assertion Markup Language. OIDC is OpenID Connect. Neither is inherently better. The right one depends on what you are building and who you are building it for, and a mature product usually ends up supporting both because its customers are split across the two camps.
The same job, described in one sentence
Both protocols answer a single question: how does an application trust that you are who you say you are, without holding your password itself? The application hands that question off to an identity provider, the system that already knows who you are. The identity provider checks you, then sends the application a signed statement that says, in effect, "this is Farhan, and I vouch for it." The application reads the statement, trusts the signature, and lets you in. SAML and OIDC are two different ways of writing and delivering that signed statement. If you want the wider picture of why organizations put an identity provider in the middle at all, I cover that in the piece on what enterprise SSO is and why buyers ask for it.
SAML: XML assertions and the enterprise heartland
SAML arrived in the mid-2000s, and it carries the design instincts of that era. Its core object is the assertion, an XML document that describes who you are and what the identity provider is willing to say about you. When you log in through SAML, the application generates an authentication request, redirects your browser to the identity provider, and the identity provider eventually posts a signed XML assertion back to the application. Your browser is the courier. It carries the request over and carries the signed assertion back, usually as a form submission.
The strength of SAML is that it was built for exactly one use case and does it well: browser-based single sign-on for enterprise web applications. It is deeply established. Corporate identity systems have spoken SAML for close to two decades, so nearly every enterprise identity provider supports it, and security teams know how to review it. When a large organization asks a vendor for SSO, SAML is very often what they mean by default, even if they do not say the word.
The cost of SAML is that XML is heavy and the signing rules are strict. The assertions are verbose, the XML signature specification is genuinely hard to implement correctly, and small mistakes in canonicalization or certificate handling turn into subtle security bugs. SAML also assumes a browser and a redirect flow. It was never designed for a mobile app talking to an API, or for one service calling another without a human present. You can force it into those shapes, but it fights you.
OIDC: JSON tokens on top of OAuth 2.0
OpenID Connect is younger, standardized in 2014, and it made a deliberate bet: build identity on top of OAuth 2.0, the authorization framework the web had already adopted for granting apps limited access to accounts. OAuth 2.0 was designed to answer "can this app do this thing on my behalf." OIDC adds a thin, well-defined layer that also answers "and who is the person behind it." That reuse is the whole idea. Instead of inventing new transport and new signing, OIDC borrowed the flows developers already knew.
Its core object is the ID token, a JSON Web Token, or JWT. A JWT is compact, it is JSON rather than XML, and it is signed in a way that is far easier to verify with modern libraries. When you log in through OIDC, the application sends you to the identity provider, you authenticate, and the provider returns an authorization code. The application exchanges that code, over a direct back-channel call, for an ID token and usually an access token. The ID token tells the app who you are. The access token lets the app call other services on your behalf.
Because OIDC inherits OAuth 2.0, it handles cases SAML struggles with. Native mobile apps, single-page web apps, and machine-to-machine calls all have well-trodden OIDC patterns. Tokens are small enough to pass around cheaply, JSON is trivial to parse in any language, and the same protocol that logs a user in can also authorize an API request a second later. For anyone building a modern application from scratch, OIDC is usually the more natural fit.
How the two flows actually differ
The clearest way to see the difference is to trace what crosses the wire. In SAML, the identity provider produces a signed XML assertion and your browser posts it to the application. The trust lives in that one XML document and its signature. In OIDC, the identity provider hands back a short code through the browser, then the application quietly redeems that code for tokens over a direct server-to-server request. The sensitive material never has to ride around in the browser. This back-channel exchange is one reason OIDC feels cleaner for anything beyond a simple web login.
There is also a difference in what you get back. A SAML assertion is essentially a login event plus a bundle of attributes about the user. An OIDC exchange gives you an identity token and, separately, an access token you can present to APIs. That split between "who you are" and "what you are allowed to call" is native to OIDC and bolted on awkwardly in SAML. If your product is really an API with a UI in front of it, that distinction matters a great deal.
| Dimension | SAML | OIDC |
|---|---|---|
| Released | Mid-2000s, mature and stable | 2014, built on OAuth 2.0 |
| Message format | Signed XML assertions | JSON Web Tokens (JWT) |
| Built on | Its own XML and signing stack | OAuth 2.0 authorization framework |
| Best fit | Enterprise browser SSO | Web, mobile, SPAs, APIs |
| Token carries | Login plus user attributes | ID token plus access token |
| Mobile and machine calls | Awkward, browser-centric | Native, well-supported |
| Who asks for it | Large enterprises by default | Modern apps and developer teams |
Why a modern app supports both
If OIDC is the cleaner design, a fair question is why anyone still bothers with SAML. The answer is not technical, it is the market. A vast installed base of enterprise identity providers speaks SAML fluently, and the security teams at those organizations have years of process built around it. When they evaluate a new tool, they want it to plug into what they already run. Telling them to adopt a different protocol because it is more elegant is a losing argument.
Newer companies and developer-focused products, on the other hand, lean toward OIDC because it fits how they build and because it extends naturally into API access. So a product that wants to serve both a fast-moving startup and a traditional enterprise ends up supporting both protocols. It is not indecision. It is meeting each customer where their identity system already is.
This is the position I took with Atlas. Atlas supports both SAML and OIDC for single sign-on, so a team can connect it to whatever identity provider they already use rather than being forced onto one protocol. I want to be precise about the boundary, though, because honesty is the whole brand here. Atlas is an AI work platform that offers SSO and an audit log. It is not an identity vendor, and it does not offer automated user provisioning, directory synchronization, or a named role framework. If you need those, an identity platform is the right tool and Atlas sits behind it as an application, not in front of it. You can read the plain version of what is and is not in place on the security page, and the fuller ground on enterprise authentication if you want the surrounding concepts.
How to choose, if you are building
If you are adding SSO to a product and you get to pick a starting point, start with OIDC. It is easier to implement correctly, the libraries are better, and it will carry you into mobile and API scenarios without a rewrite. Then add SAML when your customers ask for it, and they will, because the enterprise ones expect it. Building it in the other order is possible but harder, since SAML's signing rules punish small errors and you rarely get the API-access benefits you would from OIDC.
If you are a buyer rather than a builder, the choice is usually made for you by whatever your identity provider prefers, and most support both. What matters more is that the application you are adopting supports the protocol your provider uses, and that single sign-on is paired with strong authentication at the provider itself. The protocol is the pipe. The security of the login still comes from how carefully the identity provider verifies the person, which is why Atlas treats SSO as a connection to your existing controls rather than a replacement for them.
The mistake worth avoiding
The most common error I see is treating SSO as a checkbox that is either present or absent. It is not. A product can technically support SAML and still handle it badly: skipping signature validation, mishandling session lifetimes, or failing to log the events a security team needs to review. The protocol name on a feature list tells you almost nothing about the implementation quality underneath it. When you evaluate a tool, ask how it validates assertions or tokens, how it handles session expiry, and what it records in the audit log. Those answers reveal far more than whether the acronym appears on the page.
Is OIDC just OAuth 2.0 with extra steps?
Not quite. OAuth 2.0 is about authorization, deciding what an app is allowed to do on your behalf. OIDC is a thin identity layer added on top that also tells the app who you are, through a standardized ID token. They are closely related by design, which is exactly why OIDC was built the way it was, but OAuth 2.0 alone does not give you a reliable way to identify the user.
Is SAML outdated?
No. It is older, but it is stable, widely deployed, and the default in most enterprise identity systems. Outdated implies it should be retired, and it should not. For traditional browser-based enterprise single sign-on it works well and is deeply supported. It is simply a poor fit for mobile apps and machine-to-machine calls, which is where OIDC took over.
Can one application support both at once?
Yes, and many do. The application exposes both a SAML and an OIDC connection, and each customer connects using whichever their identity provider prefers. Atlas takes this approach so teams can use their existing provider without switching protocols.
Does supporting SSO make an app enterprise-ready?
It is one requirement, not the whole list. Enterprise buyers usually also look for an audit log, sensible session controls, and often user provisioning and formal security reports. SSO is necessary but not sufficient, and any honest vendor will tell you which of the other items it does and does not have.