SAML vs OAuth vs OIDC: What's the Difference?

SAML, OAuth, and OIDC come up constantly in enterprise authentication discussions — often in the same sentence, often used interchangeably, and almost always incorrectly. They are not competing alternatives to the same problem. Each one does something specific, and understanding that distinction will save you hours of confusion when configuring SSO, debugging token errors, or evaluating an identity provider.

One-Sentence Definitions

SAML (Security Assertion Markup Language): An XML-based protocol for exchanging authentication and authorization data between an identity provider and a service provider, primarily for enterprise SSO.

OAuth 2.0: An authorization framework that allows a third-party application to obtain limited access to a resource on behalf of a user, without exposing the user's credentials.

OpenID Connect (OIDC): An authentication layer built on top of OAuth 2.0 that lets applications verify the identity of an end user and obtain basic profile information.

SAML: Enterprise SSO with XML

SAML has been around since 2002 and remains dominant in enterprise environments. It is the backbone of most corporate single sign-on systems you interact with when logging into Salesforce, Workday, or a corporate VPN through your company's identity provider.

How it works: The user tries to access a service (the Service Provider, or SP). The SP redirects them to the identity provider (IdP — think Okta, Azure AD, ADFS). The IdP authenticates the user and sends back a digitally-signed XML document called a SAML Assertion containing who the user is and what they're allowed to access. The SP reads that assertion and grants access.

What SAML is good at:

• Browser-based enterprise SSO across internal applications
• Federating identity between organizations
• Rich attribute passing (department, role, manager, cost center)
• Compliance environments that require it by policy

What SAML is not good at:

• Mobile applications
• APIs and microservices
• Modern JavaScript frontends

You can decode a SAML assertion (they're Base64-encoded and often compressed) with the SAML Decoder to inspect the claims being passed.

OAuth 2.0: Delegated Authorization

OAuth 2.0 is not an authentication protocol. This is the most important thing to understand. OAuth answers the question: "Can Application A access Resource B on behalf of User C?" — not "who is User C?"

The classic example: You use a third-party app that wants to read your Google Drive files. OAuth lets you grant that permission without giving the app your Google password. You authenticate with Google directly, Google issues an access token to the app, and the app uses that token to call the Drive API. Google never shares your credentials with the third-party app.

Key concepts:

• Access token: A credential the client uses to call APIs — proves the bearer has been granted certain permissions (scopes)
• Refresh token: A long-lived credential used to obtain new access tokens without asking the user to log in again
• Scopes: Specific permissions being requested (read:email, write:files, etc.)
• Grant types: Different flows for different contexts — Authorization Code (web apps), Client Credentials (server-to-server), Device Code (TVs/CLIs)

OAuth on its own does not tell you who the user is. The access token proves access rights, not identity.

Inspect an OAuth access token with the OAuth Token Inspector to see what scopes and claims it contains.

OpenID Connect: Authentication on Top of OAuth

OIDC was designed specifically to solve the identity problem that OAuth 2.0 deliberately left out. It is a thin identity layer on top of the OAuth 2.0 framework.

When you log into a website using "Sign in with Google" or "Sign in with GitHub," that is OIDC in action. The flow is OAuth 2.0, but instead of just an access token, you also receive an ID token — a JWT that contains verified information about who the user is.

What OIDC adds to OAuth:

• A standardized /userinfo endpoint
• A standardized discovery document (/.well-known/openid-configuration)
• The ID token (a JWT with sub, email, name, iss, aud, iat, exp claims)
• Standardized scopes: openid, profile, email, address, phone

The sub claim in the ID token is the stable, unique identifier for the user within that identity provider. Everything else (name, email) can change. sub does not.

Use the OIDC Debugger to trace a full OIDC flow and inspect what your IdP is actually returning. The JWT Decoder lets you inspect the ID token payload directly.

Comparison Table

When to Use Each

Use SAML when:

• Your enterprise has existing SAML infrastructure (Okta, Azure AD, ADFS, Ping)
• You need SSO into SaaS applications like Salesforce, Workday, or ServiceNow
• Your compliance requirements specify SAML
• You are federating identity between two enterprise organizations

Use OAuth 2.0 when:

• You need a third-party application to access an API on behalf of a user
• You are building an API and need to issue scoped access tokens
• You need machine-to-machine authorization (Client Credentials flow)

Use OIDC when:

• You want a "Sign in with Google/GitHub/Microsoft" button on your site
• You are building a modern web or mobile app and need user authentication
• You want standardized user profile claims without building your own auth system

How They Coexist

These protocols are not mutually exclusive. A mature organization commonly uses all three simultaneously:

• Employees log into internal apps via SAML SSO (Okta as the IdP, Salesforce as the SP)
• That same Okta instance issues OIDC tokens for modern web apps built in-house
• Third-party integrations and API access use OAuth 2.0 access tokens

A single identity provider like Azure AD or Okta supports all three natively.

Practical example: A user logs into their company laptop authenticated via SAML to the corporate IdP. They open a browser-based internal tool that uses OIDC to confirm who they are. That tool calls a backend API that validates an OAuth 2.0 access token to check permissions. Three protocols, one user session.

Debugging Each Protocol

• SAML issues: Decode the assertion at SAML Decoder to inspect attributes, NotOnOrAfter expiry, and AudienceRestriction values
• JWT/OIDC issues: Paste the ID token into JWT Decoder to read claims, check expiry, and verify the issuer
• OAuth issues: Use the OAuth Token Inspector to inspect token contents and the OIDC Debugger to trace the full authorization code flow

Understanding which protocol is in play for a given system is the first step to diagnosing any authentication problem. Once you know whether you're looking at a SAML assertion, a JWT ID token, or an OAuth access token, the right debugging tool becomes obvious.