SSO vs OAuth vs OIDC vs SAML: What Each One Actually Does

Four acronyms, four different jobs. Most engineers can name all of them, but the moment someone asks, "So what's actually different between OAuth and OIDC?" the room goes quiet. The confusion is real, and it usually comes from mixing up identity, authorization, and single sign-on. This guide cuts through the noise.

The One-Line Mental Model

Protocol	Answers
SSO	"Do I need to log in again?"
OAuth 2.0	"What is this app allowed to access?"
OIDC	"Who is this user?"
SAML	"How does the enterprise IdP prove identity?"

1. Single Sign-On (SSO)

Purpose: Authenticate once, get access to multiple applications without re-entering credentials.

The canonical example is a Google account — sign in once and you're already authenticated for Gmail, YouTube, and Drive.

Use cases:

• Enterprise application suites
• Google Workspace / Microsoft 365
• Corporate identity portals

SSO isn't a protocol by itself — it's a user experience outcome, typically implemented using OIDC or SAML underneath.

2. OAuth 2.0

Purpose: Let one application access another application's resources on a user's behalf, without ever handling the user's password.

User -> clicks "Login with Google"
App  -> redirected to Google's consent screen
Google -> issues an Access Token (scoped, time-limited)
App  -> calls Google APIs using the Access Token

The app never sees the password. It only receives a token with limited, revocable permissions.

Use cases:

• "Login with Google / GitHub / Facebook" buttons
• Third-party API integrations
• Mobile app authorization
• Microservice-to-microservice authorization

Key point for interviews: OAuth is an authorization framework, not an authentication protocol. It was never designed to answer "who is this user" — that gap is exactly why OIDC exists.

3. OpenID Connect (OIDC)

Purpose: Add an authentication layer on top of OAuth 2.0.

Question	Protocol
"What can this app access?"	OAuth 2.0
"Who is the user?"	OIDC

OIDC introduces the ID Token — a signed JWT containing user identity claims (sub, email, name) — alongside the OAuth Access Token. This is what actually lets an app say "this is Alice, and she's authenticated," rather than just holding a scoped permission.

Use cases:

• "Login with Google" / "Login with Microsoft" identity flows
• Modern web and mobile authentication

4. SAML

Purpose: Enterprise-grade Single Sign-On using XML-based assertions.

SAML predates OAuth/OIDC and is still the backbone of large-org identity federation — think Salesforce, Workday, SAP, and internal enterprise tooling talking to a corporate Identity Provider (IdP).

Use cases:

• Enterprise SSO
• Corporate Identity Providers (Okta, Azure AD, PingFederate)
• Legacy enterprise application integration

Architecture Flow: How Each Protocol Actually Moves Bytes

Naming the protocols is easy. Tracing the actual request and redirect sequence is where interviews and incident reviews separate people who have read about identity protocols from people who have actually debugged them.

SSO — session reuse across apps

1. User opens App A.
2. App A redirects to the shared Identity Provider.
3. User authenticates once — 2026 default: passkey or biometric, not a password.
4. IdP issues a session and trust token back to App A.
5. App B redirects to the same IdP and reuses that session — no second login.

OAuth 2.0 — delegated, scoped access

1. App A (the client) needs to access a resource that lives in App B.
2. App A redirects the user to App B's Authorization Server.
3. User logs in and grants scoped consent rather than handing over a blanket password.
4. Authorization Server issues a short-lived Access Token — 2026 default: PKCE, even for confidential server-side clients.
5. App A calls App B's API with the Access Token attached.

OIDC — authentication layered on OAuth

1. User starts login at App A.
2. App A redirects to the OIDC Provider's /authorize endpoint.
3. User authenticates — passkey-first where the IdP supports it.
4. Provider returns a signed ID Token alongside the Access Token.
5. App A verifies the ID Token's signature and claims and opens a local identity session.

SAML — enterprise assertion exchange

1. User attempts to reach the Service Provider (SP) application.
2. SP redirects the browser to the enterprise SAML IdP.
3. User authenticates against the corporate directory.
4. IdP posts back a signed XML assertion via the browser (HTTP-POST binding).
5. SP validates the assertion's signature and creates the session.

2026 read: OIDC has become the default for anything net-new — SPAs, mobile apps, and B2C products. SAML is not going away, but it is increasingly confined to enterprises integrating against an existing corporate IdP that already speaks it. PKCE and passkeys are the two changes that matter operationally in this cycle; the rest of the flow above follows the same shape it has had since 2015.

Quick-Reference: Access Token vs ID Token

	Access Token	ID Token
Issued by	Authorization Server	OIDC Provider
Consumed by	Resource Server / API	The client app itself
Contains	Scopes/permissions	User identity claims
Format	Often opaque or JWT	Always a JWT
Answers	"What can I do?"	"Who am I?"

The Simple Way to Remember It

• SSO → Log in once.
• OAuth → Give permission.
• OIDC → Verify identity.
• SAML → Enterprise Single Sign-On.

Common Interview Questions

• What is the difference between Authentication and Authorization?
• OAuth vs OIDC — what's the actual gap OIDC fills?
• OAuth vs SAML — when would you pick one over the other?
• Is OAuth alone sufficient for authentication? Why not?
• What is an ID Token vs an Access Token?
• Walk through what happens under the hood on "Login with Google."
• When should you choose SAML over OIDC in an enterprise context?

Quick Interview Answers

• SSO lets users log in once and access multiple applications.
• OAuth 2.0 is an authorization framework that lets applications access resources on a user's behalf, without handling passwords directly.
• OIDC extends OAuth by adding authentication through a signed ID Token.
• SAML is an XML-based authentication standard used heavily in enterprise identity federation.

Production Takeaway

If you are building something new, start with OIDC. It gives you authentication, identity claims, and a much simpler path than SAML for modern apps. Use OAuth when the real goal is delegated access to APIs or resources. Use SAML when you are integrating with an existing enterprise identity stack that already depends on it. And never treat a bare OAuth access token as proof of identity — that is the exact mistake OIDC was designed to prevent.