OAuth 2.0 vs OpenID Connect vs SAML

Introduction

Authentication (who you are) and authorization (what you can do) are fundamental security concepts. Three protocols dominate this space: OAuth 2.0, OpenID Connect (OIDC), and SAML. Understanding when to use each is critical for architects and developers.

Quick Summary:

• OAuth 2.0 — Authorization protocol (grants access to resources)
• OpenID Connect — Authentication layer on top of OAuth 2.0 (proves identity)
• SAML — Enterprise authentication/authorization (XML-based, older but still widely used)

OAuth 2.0: Authorization Framework

OAuth 2.0 answers: "Can this application access my data?"

It's NOT about proving who you are—it's about granting permissions without sharing passwords.

The Core Problem OAuth Solves:

Before OAuth, if you wanted App A to access your data in Service B, you'd give App A your Service B password. This was terrible:

• App A could do anything with your account
• You couldn't revoke access without changing your password
• Password was stored in multiple places

OAuth 2.0 Flow (Simplified):

1. User clicks "Connect with Google" in your app
2. User is redirected to Google's authorization server
3. User logs in and approves specific permissions (scopes)
4. Google redirects back with an authorization code
5. Your app exchanges code for an access token
6. Your app uses the token to access Google APIs

Key Components:

• Resource Owner — The user who owns the data
• Client — The application requesting access
• Authorization Server — Issues tokens (e.g., Google, Azure AD)
• Resource Server — Hosts the protected resources (e.g., Google Drive API)

OAuth 2.0 Grant Types:

• Authorization Code — Most secure, for server-side apps
• Authorization Code + PKCE — For mobile/SPA apps (recommended)
• Client Credentials — Machine-to-machine, no user involved
• Device Code — For devices without browsers (Smart TVs, CLI tools)

What OAuth 2.0 Does NOT Do:

• It doesn't tell you WHO the user is
• It doesn't provide user profile information
• It's purely about authorization, not authentication

OpenID Connect (OIDC): Identity Layer

OIDC answers: "Who is this user?"

OpenID Connect adds an identity layer on top of OAuth 2.0. It provides a standardized way to authenticate users and get basic profile information.

What OIDC Adds to OAuth 2.0:

• ID Token — A JWT containing user identity claims
• UserInfo Endpoint — API to get additional user details
• Standard Scopes — openid, profile, email, etc.
• Discovery — .well-known/openid-configuration endpoint

OIDC Flow:

Same as OAuth 2.0, but:

1. Include openid scope in the request
2. Receive an ID Token along with the access token
3. ID Token contains user info (sub, name, email, etc.)

ID Token Contents (JWT):

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "your-client-id",
  "exp": 1702000000,
  "iat": 1701996400,
  "name": "John Doe",
  "email": "john@example.com",
  "picture": "https://..."
}

When to Use OIDC:

• "Sign in with Google/Microsoft/Facebook"
• Single Sign-On (SSO) for web applications
• When you need to know user identity
• Modern web and mobile applications

SAML: Enterprise Federation

SAML (Security Assertion Markup Language) answers: "Trust this other organization's authentication."

SAML is older (2005) and XML-based, but remains dominant in enterprise environments.

SAML Components:

• Identity Provider (IdP) — Authenticates users (e.g., Okta, Azure AD)
• Service Provider (SP) — Your application that trusts the IdP
• Assertions — XML documents containing identity/authorization info

SAML Flow (SP-Initiated):

1. User tries to access your app (SP)
2. SP redirects to IdP with SAML Request
3. User authenticates at IdP
4. IdP sends SAML Response (signed XML) back to SP
5. SP validates signature and grants access

SAML Assertion Contents:

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>john@company.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="..." NotOnOrAfter="..."/>
  <saml:AttributeStatement>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>admin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

When to Use SAML:

• Enterprise SSO with legacy systems
• B2B integrations with large organizations
• When partners require SAML
• Compliance requirements specifying SAML

Comparison: When to Use What

OAuth 2.0:

• API authorization
• Third-party app access
• Mobile apps accessing backend APIs
• When you only need permissions, not identity

OpenID Connect:

• User authentication ("Sign in with...")
• Modern SSO for web/mobile apps
• When you need user profile info
• New projects starting fresh

SAML:

• Enterprise SSO
• Legacy system integration
• When your enterprise IdP requires it
• B2B federation with large companies

Real-World Architecture Patterns

Pattern 1: Consumer App (OIDC)

Mobile App → OIDC → Google/Apple Sign-In → Backend API

Pattern 2: Enterprise SSO (SAML)

Employee → Corporate Portal → SAML → Okta → SaaS Apps

Pattern 3: API Gateway (OAuth 2.0)

Client App → OAuth 2.0 → API Gateway → Microservices

Pattern 4: Hybrid (Common in Enterprises)

Internal Users → SAML → IdP
External Users → OIDC → Social Login
Both → OAuth 2.0 tokens → Backend APIs

Cloud Provider Implementations

Azure AD / Entra ID:

• Supports SAML, OAuth 2.0, and OIDC
• Microsoft Identity Platform for developers
• B2B and B2C scenarios

AWS Cognito:

• User pools (OIDC provider)
• Identity pools (federation)
• SAML federation support

Google Cloud Identity:

• Google Sign-In (OIDC)
• Workforce Identity Federation
• SAML app integration

Security Best Practices

1. Always use HTTPS — Tokens in transit must be encrypted
2. Validate tokens properly — Check signature, issuer, audience, expiration
3. Use PKCE for public clients — Prevents authorization code interception
4. Short-lived access tokens — Use refresh tokens for longer sessions
5. Secure token storage — Never store tokens in localStorage for sensitive apps
6. Implement proper logout — Revoke tokens, clear sessions

Common Mistakes

• Using OAuth 2.0 for authentication (use OIDC instead)
• Storing tokens insecurely in browsers
• Not validating token signatures
• Overly broad scopes
• Not implementing token refresh properly
• Mixing up ID tokens and access tokens

Exam Tips

For Azure (AZ-900, AZ-104, AZ-500):

• Azure AD supports all three protocols
• Know when to use each for different scenarios
• Understand B2B vs B2C

For AWS (Cloud Practitioner, Solutions Architect):

• Cognito User Pools = OIDC
• Cognito Identity Pools = Federation
• SAML for enterprise identity federation

For Security+ / CISSP:

• Know the security implications of each
• Understand token-based vs session-based auth
• Federation concepts and trust relationships

Key Takeaway

OAuth 2.0 is for authorization (permissions), OIDC is for authentication (identity), and SAML is for enterprise federation. Modern apps typically use OIDC for authentication and OAuth 2.0 for API access. SAML remains important for enterprise integrations. Understanding which to use and how they work together is essential for building secure systems.