SAML vs OAuth
A short, practical guide to SAML. How it works, who uses it, what the certificates are for, and why it's a different thing from OAuth.
If you’ve ever clicked “Sign in with your company account” and been bounced through a couple of redirects before landing back where you started, there’s a good chance you’ve used SAML. It’s the protocol that still quietly powers single sign-on (SSO) across a lot of enterprise software.
SAML is the older of the two standards covered here. It was appeared in 2005 and still runs a huge share of enterprise SSO today. New projects, though, increasingly implement OpenID Connect (OIDC) instead. Both approaches coexist, and many serious B2B SaaS vendors support both.
This post is a short tour of what SAML is, how it works, and why it isn’t the same thing as OAuth, even though people often lump them together.
What SAML is for
SAML stands for Security Assertion Markup Language. It’s an XML-based standard for one system to tell another, “this user is who they say they are, and here’s some information about them.”
It’s built for single sign-on, giving you get access to many applications without signing in again.
Typical users:
- Large organisations with hundreds of SaaS tools
- Universities and government departments
- Any B2B SaaS vendor selling into the enterprise (SAML support is often a hard requirement)
Examples of a dominant identity providers (IdP) in this space are Microsoft Entra ID (formerly Azure AD) and Google.
The three parties
Every SAML flow has three actors:
- The user trying to access something
- The Service Provider (SP) — the application the user wants to use (Salesforce, Slack, your SaaS product)
- The Identity Provider (IdP) — the system that holds the user’s identity (Microsoft Entra ID, etc.)
The SP trusts the IdP to vouch for users. The user trusts the IdP to handle their credentials. The SP and the user never directly exchange a password.
How it works
Here’s the typical flow:
- User visits the Service Provider.
- The SP sees they’re not logged in and generates a SAML Authentication Request. This is bundled into a redirect to the Identity Provider.
- The user lands at the IdP. If they’re not already logged in, they authenticate there (password, MFA, whatever the IdP enforces).
- The IdP builds a SAML Assertion. This is an XML document that says “this is Alice, here’s her email, here are her groups, and this assertion is valid for the next 5 minutes.” The IdP signs the assertion with its private key.
- The IdP sends the assertion back to the user’s browser, which posts it to the SP’s Assertion Consumer Service URL.
- The SP validates the signature using the IdP’s public key certificate (which was shared when the system was initally setup). If the signature checks out and the assertion is fresh, the user can be logged in to the SP.
No passwords cross between the SP and IdP. The user’s browser is the courier, carrying a signed XML document.
Certificates and trust
Before any of this works, the SP and IdP have to exchange trust. That usually means:
- The IdP gives the SP its X.509 public key certificate. The SP uses this to verify every assertion.
- The SP tells the IdP its Assertion Consumer Service URL (where to post assertions).
- Optionally, the SP signs its authentication requests too, so the IdP can verify them.
Certificate expiry is one of the most common causes of SSO outages, so special care should be taken here.
The signing itself is standard public-key cryptography. The IdP hashes the assertion and encrypts the hash with its private key. The SP decrypts it with the public key and compares hashes. Tamper with the assertion and the signature no longer matches.
How SAML differs from OAuth
SAML and OAuth are similar because both involve redirects, tokens, and third-party identity. But they’re built for different jobs.
SAML is about authentication. It answers the question: who is this user? The assertion is the end goal. Once the SP has a valid assertion, the user is logged in.
OAuth is about authorisation. It answers the question: can this application act on behalf of this user? OAuth issues access tokens that let a client call an API. “Let this app read my Google Calendar” is a classic OAuth use case.
A few concrete differences:
| SAML | OAuth 2.0 | |
|---|---|---|
| Primary purpose | Authentication (SSO) | Authorisation (API access) |
| Format | XML | JSON (typically JWT) |
| Typical users | Enterprise employees | Consumer and developer apps |
| Carries identity? | Yes, natively | Only with OIDC layered on top |
| Size | Verbose | Compact |
OpenID Connect (OIDC) is worth mentioning here. It’s a thin identity layer built on top of OAuth 2.0 that adds an ID token (a signed JWT with user info). OIDC is what most modern consumer “Log in with Google” flows use. You can think of it as the modern answer to what SAML does, but built on OAuth plumbing.
When to use which
Rough guide:
- B2B SaaS selling to enterprises? You need SAML. It’s table stakes for IT procurement.
- Building a consumer app with social login? Use OIDC (OAuth-based).
- Need an app to call an API on a user’s behalf? OAuth.
- Want to federate identity across many SaaS tools inside one company? SAML (or increasingly OIDC, but SAML still dominates the enterprise directory space).
Many organisations end up using both.
Conclusion
SAML is the older of the two federated identity standards. It’s verbose, XML-based, and does one thing very well: tell an application, with cryptographic confidence, who the user is. It still runs most enterprise SSO, and it won’t disappear any time soon, but new integrations increasingly choose OIDC instead. Expect to see SAML dominate the installed base for years, while greenfield work drifts towards OIDC.
OAuth solves a different problem altogether (delegated API access), and OIDC is the modern layer on top that makes OAuth useful for identity.
If you’re evaluating an authentication approach, the question to ask first isn’t “SAML or OAuth?” but “am I authenticating a user, or authorising an application?” The answer usually picks the protocol for you.