SAML vs OAuth vs OIDC, and Real-World Usage

Part 5 of the SAML From First Principles series

The most common question about SAML: "Why not just use OAuth?" Let's reason through it, then look at how SAML actually shows up in the real world.

SAML: the enterprise SSO era

SAML was designed in the early 2000s for enterprise web-based single sign-on. It uses XML, it's verbose, and it works through browser redirects and form POSTs. It was built for a world where employees sit at desktops and access web applications through a browser.

For that use case, SAML works extremely well. It's mature, battle-tested, and supported by every major enterprise identity provider and application.

Then the world changed

Mobile apps appeared. SAML's redirect-based flow doesn't work well on mobile because there's no browser to redirect through.

APIs became the backbone of everything. SAML has no native way to protect API calls.

JSON replaced XML as the preferred data format. Developers wanted something lighter.

OAuth 2.0: authorization, not authentication

OAuth 2.0 was created to solve a different problem: authorization. It answers "Is this application allowed to access this resource on behalf of the user?" It does not answer "Who is this user?"

OAuth issues access tokens that grant specific permissions. But an access token doesn't tell you who the user is. It tells you what the application is allowed to do.

OpenID Connect: authentication on top of OAuth

OIDC was built on top of OAuth 2.0 to add the missing piece: authentication. It introduces an ID Token (a JWT) containing the user's identity. OIDC gives you both authentication and authorization in a lightweight, JSON-based protocol that works for browsers, mobile apps, and APIs.

The comparison

When to use what

Use SAML for enterprise SSO with browser-based applications, especially when integrating with existing enterprise IdPs that already support SAML. Most legacy enterprise applications support SAML.

Use OIDC for new applications, mobile apps, single-page applications, and anything that needs API authentication. Simpler, lighter, and more versatile.

Use OAuth 2.0 when you need delegated authorization for API access without needing to know who the user is.

In practice, many organizations use both. SAML for legacy enterprise applications. OIDC for new applications. Most identity providers support both protocols.

SAML limitations that drove the shift

• XML is verbose (kilobytes vs hundreds of bytes for a JWT)
• Browser-only (no mobile, no SPA, no server-to-server)
• No native API authentication
• Complex certificate management
• Single Logout is fragile

OIDC solves all of these with discovery documents, JWKs for key management, compact JWTs, and standard token formats that work in HTTP headers.

The trend

New applications use OIDC. Existing enterprise applications keep SAML. The migration is gradual. SAML isn't going away. There are thousands of enterprise applications that only support SAML. But if you're building something new, OIDC is the better choice.

Real-World SAML

AWS IAM Identity Center

The recommended way to give humans access to AWS accounts using SAML.

The problem: you have 15 AWS accounts and 50 engineers. Creating IAM users in every account is unmanageable.

AWS Identity Center acts as the SP. Your corporate IdP (Okta, Azure AD) is the IdP. The flow:

1. You go to the AWS access portal
2. Identity Center redirects you to your corporate IdP
3. You authenticate (or the session cookie handles it)
4. The IdP sends a SAML assertion back to Identity Center
5. Identity Center shows you your AWS accounts and permission sets
6. You pick an account and role
7. Identity Center calls STS AssumeRole and gives you temporary credentials

The SAML assertion carries who you are and what groups you belong to (mapped to permission sets). You never get permanent IAM access keys. Just short-lived STS tokens.

AWS IAM Federation (Direct SAML with STS)

The older approach, before Identity Center. Still widely used in legacy setups.

The SAML assertion goes directly to AWS STS:

1. You authenticate at your IdP
2. The IdP sends a SAML assertion
3. You call STS AssumeRoleWithSAML, passing the assertion and the IAM role ARN
4. STS validates the assertion and returns temporary credentials

This requires creating an IAM SAML Identity Provider (uploading your IdP's metadata) and creating IAM roles with trust policies that reference that SAML provider.

Google Workspace as SAML IdP

Google Workspace can act as a SAML IdP for third-party applications. If your company uses Google for email, you can configure Google as the IdP for Salesforce, Slack, Zoom.

The SSO magic is visible here. If you're already in Gmail, you never see a login page for Salesforce. The session cookie at Google does the work.

Common SAML integrations

The pattern is always the same

Every integration follows the same pattern:

1. Trust is established by exchanging metadata and certificates
2. User hits the SP, SP redirects to IdP
3. User authenticates at the IdP (once, if no session exists)
4. IdP sends a signed assertion with user identity and claims
5. SP validates the signature, reads the claims, creates a session

The only things that change are what claims the SP needs, what NameID format is used, and whether encryption is required. Because SAML is a protocol, not a product, any IdP can talk to any SP.

Previous: SAML Security Pitfalls

This concludes the SAML From First Principles series.