SAML vs SSO (and Where OAuth and OIDC Fit)

Someone asks whether the new SaaS app "supports SSO", the vendor says "yes, SAML", and half the room nods without being sure those are different answers. They are: single sign-on is the result a user sees, and SAML is one of several protocols that deliver it. This guide settles SAML vs SSO in plain terms, then shows where OAuth and OpenID Connect fit, which one to pick for a given app, and what breaks after go-live.

TL;DR

• SSO is the outcome: one sign-in at an identity provider, then access to many apps without typing a password again.
• SAML 2.0 is an XML-based standard from 2005 that delivers SSO, mostly for web apps in the workforce world.
• OAuth 2.0 is for authorization. It lets an app act on a user's behalf with limited access, and it doesn't say who the user is.
• OpenID Connect adds identity on top of OAuth 2.0 with a signed JSON token, and it's the default for new and mobile apps.
• Microsoft's own guidance: choose OpenID Connect or OAuth when the app supports it, and SAML for existing apps that don't.
• The failures to plan for are expiring signing certificates, stolen tokens and forged assertions. The protocol choice matters less.

SSO Is the Outcome, SAML Is One Route to It

Single sign-on means a user proves who they are once, to one trusted service, and every connected app accepts that proof. The trusted service is the identity provider (IdP): Microsoft Entra ID, Okta, Google Workspace, JumpCloud and similar. The apps are service providers, or relying parties in OpenID Connect terms.

SSO describes the experience. The plumbing varies: Microsoft Entra ID alone lists OpenID Connect, OAuth, SAML, password-based, linked, Integrated Windows Authentication and header-based options for connecting apps. A user clicking an app tile can't tell which one is running underneath.

SAML, short for Security Assertion Markup Language, is one of those routes. Version 2.0 became an OASIS standard on 15 March 2005, and it's still the route enterprise SaaS apps offer first. So the fair answer to "SAML vs SSO" is that they sit at different levels. You don't pick one over the other. You pick SSO as the goal, then pick the protocol each app supports.

Windows admins have used SSO for decades without calling it that. A user signs in to a domain-joined PC, and Kerberos tickets get them into file shares, printers and intranet sites with no second prompt. SAML and OpenID Connect extend the same idea to web apps outside the domain, where Kerberos can't reach.

That distinction matters for identity and access management as a whole. SSO is one building block next to MFA, provisioning and access reviews, and our guide to IAM solutions shows how the pieces connect.

How SAML SSO Works, Step by Step

Three parties take part: the user's browser, the service provider (the app) and the identity provider. They never share a password. They share a signed statement, called an assertion, that says who the user is and when they signed in.

Here is the common flow, which starts at the app and is called SP-initiated:

1. The user opens the app and enters an email address or clicks "Sign in with SSO".
2. The app builds a SAML request and redirects the browser to the IdP.
3. The IdP signs the user in, with MFA and any conditional access rules it enforces.
4. The IdP creates an XML assertion with the user's identity and attributes, signs it with its private key and posts it back through the browser.
5. The app checks the signature against the IdP's public certificate, reads the attributes and starts a session.

The same flow can start at the IdP instead, when a user clicks an app tile in a portal like My Apps or the Okta dashboard. That's IdP-initiated SSO, and it skips steps 1 and 2.

Setup is a metadata swap. The app gives the IdP its entity ID and its Assertion Consumer Service (ACS) URL, where assertions get posted. The IdP gives the app its entity ID, its sign-in URL and a signing certificate. Get one character wrong in either URL and users see a generic error with no clue why.

SP-initiated sign-in is the safer default. The app asks for the assertion, so it can tie the response to its own request. IdP-initiated sign-in is convenient for portal users, but the app receives an assertion it never asked for, which some security teams turn off for that reason.

Two details decide how much trouble SAML gives you later. The signing certificate expires, and Microsoft Entra ID creates it with a default validity of three years. And attribute mapping, meaning which field carries the email address or group membership, varies from app to app, so every new app needs its own claims check.

Where OAuth and OpenID Connect Fit

OAuth 2.0 answers a different question. Its RFC, published in October 2012, says the framework "enables a third-party application to obtain limited access to an HTTP service." Think of a backup tool reading a mailbox, or a scheduling app writing to a calendar. The app gets an access token with specific scopes, and the user never hands over a password.

OAuth on its own says nothing reliable about who the user is. An access token proves the app may do something. It doesn't prove which person is sitting at the keyboard. Teams that used raw OAuth for sign-in ended up building their own identity checks on top, each slightly different.

OpenID Connect (OIDC) fixed that. The spec calls it "a simple identity layer on top of the OAuth 2.0 protocol." It adds an ID token, a signed JSON Web Token (JWT) with the user's identity, issuer and expiry. Where SAML carries XML through browser form posts, OIDC carries compact JSON that mobile apps, single-page apps and APIs handle easily.

So the working map has three parts. SAML signs people in to web apps and is strongest in enterprise SaaS and older line-of-business apps. OAuth 2.0 grants delegated access to APIs, including the consent screens users click through. OpenID Connect signs people in to web, mobile and native apps, built on OAuth plumbing.

One more acronym turns up in the same vendor docs: SCIM, the standard for creating and removing user accounts in apps automatically. SSO decides who can sign in today. SCIM decides whether the account still exists tomorrow, which matters the day someone leaves.

This ByteMonk explainer walks through SAML, OIDC and SCIM in about ten minutes:

SAML vs OIDC vs OAuth Side by Side

The table shows the split in one line: SAML and OIDC sign people in, OAuth grants access. When a vendor says "we support OAuth SSO", ask whether they mean OpenID Connect, since plain OAuth doesn't prove identity.

For an IT team the protocol rarely changes the user experience. It changes the setup work and the failure you'll debug. SAML breaks loudly when a certificate expires. OIDC breaks when a redirect URI changes after an app update. OAuth breaks quietly, through a consent grant nobody reviewed.

Which One to Pick for a Given App

The app usually decides for you. Open its SSO settings page and see what it lists. When it offers both, Microsoft's Entra planning guide gives a clean rule: choose OpenID Connect and OAuth "if the application you're connecting to supports it", and choose SAML "whenever possible for existing applications that don't use OpenID Connect or OAuth."

In practice that gives a short order for each new app. If it supports OIDC, use it, especially for mobile or single-page apps. If it supports only SAML, use SAML and log the certificate expiry date the day you set it up.

If it supports neither but has a web login page, use password-based SSO (password vaulting) from the IdP, so users stop reusing passwords. On-premises apps can use Integrated Windows Authentication or header-based SSO through an app proxy. An app with no SSO option at all goes on the replacement list, covered by a password manager and MFA in the meantime.

Two checks apply whatever the protocol. First, confirm the app can enforce SSO and turn off local passwords, or users keep a side door open. Second, check whether SSO sits behind a higher pricing tier. Some SaaS vendors reserve SAML for enterprise plans, and admins on r/sysadmin have complained about that "SSO tax" for years. Factor it into the renewal before you promise a client one sign-in for everything.

Apps that nobody in IT signed up for won't appear in any of this. Our post on shadow IT covers finding them first, because an app you don't know about never gets SSO.

What Goes Wrong: Certificates, Tokens and Forged Assertions

SSO concentrates trust. One identity provider now vouches for every app, so the IdP's keys and tokens become the target. Four failure points come up again and again.

Expired signing certificates. A SAML certificate that expires breaks sign-in for every user of that app at once. The fix takes five minutes, if someone knows where the new certificate goes and has admin access to the app. This r/sysadmin thread is a typical example, asking how to renew an expiring SAML signing certificate between Jamf Pro and Okta:

Forged assertions from a stolen signing key. If an attacker steals the IdP's token-signing certificate, they can mint valid SAML tokens for any user. CISA's advisory AA20-352A, on the 2020 SolarWinds-linked campaign, describes exactly this: the adversary "creates unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment." The technique is known as Golden SAML, and MFA doesn't stop it because the forged token claims MFA already happened. Protect the signing key like a domain admin credential.

Broken signature checks in the app. The app has to verify every signature correctly, and libraries get this wrong. CVE-2024-45409, published on 10 September 2024, let an unauthenticated attacker forge a SAML response in the Ruby-SAML library and "log in as arbitrary user", with a CVSS score of 10.0. Patching the apps that consume SAML matters as much as securing the IdP.

Stolen and phished tokens. OAuth and OIDC have their own version of the problem. Microsoft reported in February 2025 that the group it tracks as Storm-2372 used device code phishing to capture tokens, then read mail and moved laterally. In Microsoft's words: "The threat actor continues to have access so long as the tokens remain valid." Short token lifetimes, sign-in risk policies and a quick revoke-sessions routine limit the damage.

None of these are reasons to avoid SSO. One strong front door with MFA beats forty apps with forty reused passwords, and our breakdown of the most common passwords shows what those forty doors tend to look like. They are reasons to treat the IdP as the most important system you run.

Rolling Out SSO on a Small Team

A small IT team or an MSP can roll out SSO client by client without a big project. A workable order:

1. Pick the IdP the client already pays for. For a Microsoft 365 tenant that's usually Entra ID; for a Google Workspace shop, Google. Adding a second IdP adds a second front door.
2. Lock down the IdP first. Phishing-resistant MFA for admins, conditional access for everyone, and two break-glass accounts excluded from policies and stored offline.
3. Connect the high-value apps. Email is already covered; next come the finance, HR, file-sharing and remote access tools.
4. Turn on SCIM where the app supports it, so leavers lose access when their directory account does. Where it doesn't, add the app to the offboarding checklist by name.
5. Keep a certificate register. One row per SAML app: expiry date, owner, where the new certificate gets uploaded. Put reminders at 60 and 14 days.
6. Review consent grants. Check which third-party apps users have granted OAuth access to, and remove the ones nobody recognizes.

Permissions still need design after SSO. SSO decides who can sign in; roles decide what they can do once inside, and our guide to role-based access control covers that half.

MSPs running identity for many tenants face the same work at scale. Our Okta for MSPs review looks at it tenant by tenant.

Measure the rollout by what the sign-in logs show. The count of connected apps says less. The useful numbers are how many sign-ins still hit local app passwords, how many users are excluded from conditional access, and how many SAML apps have a certificate expiring in the next 90 days. When those three trend toward zero, SSO is doing its job.

On the endpoint side, OpenFrame can run a script such as dsregcmd /status across a client's devices and collect the output, which shows quickly which machines are joined to Entra ID and ready for device-based conditional access.

This r/sysadmin thread shows the mixed reality of a real setup, where one tool can be wired to Entra ID through either SAML or OIDC:

The Short Answer

SSO is what users get: one sign-in, many apps. SAML is one protocol that delivers it, strongest for enterprise web apps. OpenID Connect delivers the same result with JSON tokens and suits new and mobile apps. OAuth handles delegated API access, and sign-in sits outside its job. Pick OIDC where an app offers it, SAML where it doesn't, and spend your real effort on the IdP: MFA, certificate tracking, token revocation and offboarding.

For the wider picture of directories, provisioning and access reviews, read our guide to IAM solutions next.