Skip to main content

SAML vs OAuth 2.0 – Concepts, Workflows, and Use Cases

1. Introduction​

In modern identity and access management (IAM), SAML and OAuth 2.0 are two of the most commonly used standards. They solve related but different problems:

  • SAML: Primarily used for Single Sign-On (SSO) between organizations and applications (web browser-based).
  • OAuth 2.0: Primarily used for delegated authorization (granting limited access to APIs/resources on behalf of a user).

This document explains:

  • Core concepts of SAML and OAuth 2.0
  • Architectural components
  • Typical workflows
  • Common use cases
  • How to choose between them

2. SAML (Security Assertion Markup Language)​

2.1 What is SAML?​

SAML is an XML-based standard for exchanging authentication and authorization data between security domains. It is typically used for browser-based SSO between an Identity Provider and one or more Service Providers.

  • Version: SAML 2.0 is the most widely used.
  • Format: XML-based assertions.
  • Primary use: AuthN + limited AuthZ for Web SSO.

2.2 Core Components​

  • Identity Provider (IdP)
    System that authenticates the user (e.g., corporate IdP, ADFS, Okta, Keycloak).

  • Service Provider (SP)
    Application or service the user wants to access (e.g., Salesforce, Jira, internal web app).

  • SAML Assertion
    XML document issued by IdP containing user identity and attributes (subject, roles, groups, etc.).

  • Bindings & Profiles
    Mapping between SAML messages and protocols such as HTTP Redirect, HTTP POST.

2.3 SAML SSO Workflow (IdP-Initiated)​

Scenario: User logs in from a corporate portal (IdP) and is then redirected to the Service Provider.

  1. User accesses IdP

    • User opens the corporate portal (IdP).
    • Logs in using username/password, MFA, etc.

  2. User selects application (SP)

    • From the portal, user clicks an icon/link for App A (Service Provider).

  3. IdP generates SAML Assertion

    • IdP creates a signed SAML assertion containing:
      • User identity (NameID, email, etc.)
      • Attributes (groups, roles, department, etc.)
      • Conditions (validity time, audience restriction).

  4. IdP sends SAML Response to SP

    • IdP posts SAML Response (containing assertion) to SP’s Assertion Consumer Service (ACS) via HTTP POST.

  5. SP validates assertion

    • SP verifies:
      • XML signature (using IdP’s public key).
      • Audience.
      • Validity period.
    • If valid, SP creates a local session for the user.

  6. User is granted access

    • User is now authenticated on SP without entering credentials again.

2.3.1 SAML SSO (SP-Initiated) – Workflow Summary​

Scenario: User directly accesses the application (SP) URL.

  1. User browses to SP.
  2. SP detects no local session, redirects user to IdP with a SAML AuthnRequest.
  3. IdP authenticates user (if not already).
  4. IdP sends SAML Response (assertion) back to SP ACS endpoint.
  5. SP creates session and grants access.

2.4 SAML Use Cases​

  • Enterprise Web SSO

    • Single sign-on to SaaS apps: Salesforce, ServiceNow, Confluence, etc.
    • User logs in once with corporate credentials and accesses many apps.

  • B2B Federation

    • Partner organizations use their own IdP to access your web apps.
    • Avoids managing external users’ credentials.

  • Legacy Web Applications

    • Older web apps that rely on browser redirects and server-side sessions.

2.5 SAML Pros & Cons​

Pros

  • Mature and widely adopted in enterprise environments.
  • Strong support for browser-based SSO.
  • Attribute-based access via assertions (groups/roles).

Cons

  • XML-based (heavy, verbose).
  • Primarily web-browser centric; not ideal for mobile/native/API use.
  • Implementations can be complex (metadata, certificates, etc.).

3. OAuth 2.0​

3.1 What is OAuth 2.0?​

OAuth 2.0 is an authorization framework that enables a client application to obtain limited access to a protected resource on behalf of a resource owner, without sharing the resource owner’s credentials.

Key points:

  • Focus: Delegated authorization, not direct authentication.
  • Typical use: Obtaining access tokens for APIs.
  • Token types: Access tokens (and optionally refresh tokens).

Note: To handle authentication (login + user identity) on top of OAuth 2.0, we often use OpenID Connect (OIDC).

3.2 Core Roles​

  • Resource Owner

    • Typically the end user who owns the data or resource.

  • Client

    • Application requesting access on behalf of the user (e.g., mobile app, SPA, backend service).

  • Authorization Server

    • Issues tokens after authenticating the user and authorizing the client (e.g., Keycloak, Auth0, Okta).

  • Resource Server

    • API or service that hosts protected resources and validates access tokens (e.g., REST API).

3.3 Common OAuth 2.0 Flows​

3.3.1 Authorization Code Flow (with PKCE for public clients)​

Scenario: Web app or SPA needs to call an API on behalf of the user.

  1. Client redirects user to Authorization Server

    • Includes:
      • client_id
      • redirect_uri
      • scope (e.g., openid profile email api.read)
      • response_type=code
      • code_challenge (for PKCE)

  2. User authenticates & authorizes

    • User logs in at Authorization Server.
    • User approves requested scopes.

  3. Authorization Server redirects back with code

    • Redirect to redirect_uri?code=AUTH_CODE.

  4. Client exchanges code for tokens

    • Client sends:
      • client_id (+ client_secret if confidential client)
      • code_verifier (for PKCE)
      • authorization code
    • Authorization Server returns:
      • access_token
      • optionally refresh_token
      • optionally id_token (if OpenID Connect is used).

  5. Client calls Resource Server

    • Client sends access_token in the Authorization: Bearer <token> header.
    • Resource Server validates token and returns data.

3.3.2 Client Credentials Flow (Machine-to-Machine)​

Scenario: Backend service A calls service B with no end user.

  1. Service A sends client_id + client_secret to Authorization Server.
  2. Authorization Server issues an access token (scoped for service-to-service use).
  3. Service A calls Service B API with this token.

3.4 OAuth 2.0 Use Cases​

  • API Access on Behalf of User

    • Mobile/SPA accessing backend APIs with user context.
    • “Login with X” style flows when combined with OIDC.

  • Third-Party App Access

    • Example: A calendar app accessing Google Calendar on your behalf.
    • User grants permissions (scopes) without sharing their password.

  • Service-to-Service / Microservices

    • Microservices use client credentials flow to call each other securely.

  • IoT and Devices

    • Limited-input devices using device authorization flow.

3.5 OAuth 2.0 Pros & Cons​

Pros

  • Designed for API authorization.
  • Multiple flows supporting web, mobile, SPA, and machine-to-machine.
  • Fine-grained scope-based permissions.

Cons

  • Does not define authentication by itself (must use OIDC or custom).
  • Misconfiguration can lead to serious security issues.
  • Many different grants and patterns can be confusing.

4. SAML vs OAuth 2.0 – Comparison​

AspectSAMLOAuth 2.0
Primary PurposeAuthentication (SSO)Authorization (API access)
Data FormatXML (SAML Assertions)JSON-based tokens (often JWT)
Typical UseWeb SSO, enterprise federationAPI / mobile / SPA access
Transport MechanismBrowser redirects, HTTP POSTHTTP-based (redirects + REST)
Token TypeSAML AssertionsAccess Tokens, Refresh Tokens
Best Paired WithLDAP/AD, enterprise IdPsOpenID Connect (for login)
Client TypeWeb apps (server-rendered)Web, mobile, SPA, services

5. Example Workflows & Use Cases​

5.1 Workflow: SAML-Based SSO for Enterprise Web App​

Scenario: Internal user accessing a third-party SaaS tool using SSO.

  1. User goes to the SaaS app URL (SP).
  2. SP redirects user to corporate IdP with SAML AuthnRequest.
  3. IdP authenticates the user with corporate credentials.
  4. IdP issues and signs a SAML assertion containing:
    • UserID
    • Email
    • Group memberships (e.g., HR, IT, Admin).
  5. Browser posts SAML assertion to SP’s ACS endpoint.
  6. SP validates signature, audience, and expiry.
  7. Based on attributes, SP assigns roles (e.g., admin, viewer).
  8. User is logged into the SaaS app with no separate username/password.

Use Case Fit

  • Best for: Corporate portals, SaaS SSO, “one login for many web apps.”
  • Bad fit for: APIs, mobile app backend access, microservices.

5.2 Workflow: OAuth 2.0 + OIDC for SPA + API​

Scenario: Single Page Application (React/Angular/Vue) that calls a backend API.

  1. User opens SPA in browser.
  2. SPA redirects user to Authorization Server (OIDC provider) with:
    • response_type=code
    • client_id, redirect_uri
    • scope: openid profile email api.read
    • PKCE code_challenge.
  3. User authenticates at Authorization Server and approves scopes.
  4. Authorization Server redirects back with code.
  5. SPA exchanges code + code_verifier for:
    • access_token (for API)
    • id_token (for login/user info)
    • optional refresh_token.
  6. SPA stores tokens (securely) and calls backend API using:
    • Authorization: Bearer <access_token>.
  7. API validates token (signature, expiry, audience, scopes).
  8. API returns data; SPA renders user’s dashboard.

Use Case Fit

  • Best for: Modern web apps + API, mobile applications.
  • Supports: Fine-grained API scope permissions.

5.3 Workflow: Service-to-Service with OAuth 2.0 Client Credentials​

Scenario: Microservice A calls Microservice B automatically, no user involved.

  1. Microservice A has:
    • client_id = service-a
    • client_secret = ****
  2. A calls Authorization Server /token endpoint with:
    • grant_type=client_credentials
    • scope=service-b.read.
  3. Authorization Server returns access_token for service-b.read.
  4. A calls B’s API with:
    • Authorization: Bearer <access_token>.
  5. B validates the token and returns data to A.

Use Case Fit

  • Best for: Internal microservices, backend-to-backend integration.
  • Not appropriate for: End-user login flows.

6. Choosing Between SAML and OAuth 2.0​

6.1 When to Use SAML​

  • Enterprise web-based SSO between IdP and traditional web applications.
  • Integration with SaaS products that natively support SAML.
  • B2B federated SSO with partner organizations.
  • You mainly care about “login once, access multiple web apps”.

6.2 When to Use OAuth 2.0 (+ OIDC)​

  • Mobile apps, SPAs, and modern web frontends calling APIs.
  • Microservice architectures where services call each other.
  • Use cases needing fine-grained, scope-based API access.
  • “Login with X” social logins (Google, GitHub, Facebook) via OIDC.

6.3 Combined Patterns​

In modern architectures, you may see:

  • SAML for user SSO into a central portal.
  • OAuth 2.0/OIDC tokens used by frontends and microservices behind that portal.

Example:

  1. User logs in to corporate portal via SAML.
  2. Portal or gateway exchanges SAML assertion for OAuth/OIDC tokens.
  3. Those tokens are used for API calls within the environment.

7. Summary​

  • SAML is strongest for enterprise web SSO between organizations and web apps.
  • OAuth 2.0 is the standard for delegated API authorization, often combined with OIDC for authentication.
  • Both can coexist in a modern IAM architecture:
    • SAML at the “edge” for federation.
    • OAuth 2.0/OIDC internally for APIs, microservices, and modern clients.

Use:

  • SAML when your primary need is SSO for web apps.
  • OAuth 2.0 (+ OIDC) when your primary need is secure API access, mobile/SPA auth, and microservices.