Comparing OAuth2, OpenID Connect (OIDC), and SAML — With Real Examples

Series: Web Authentication Demystified — From Concepts to Real-World

If there’s one source of confusion in authentication discussions, it’s this:
people often talk about OAuth2, OIDC, and SAML as if they’re interchangeable. They aren’t. They solve related problems, but at different layers, with different assumptions, and very different ergonomics.

This article clarifies how these standards compare by answering three practical questions:

• What problem does each one actually solve?

• What does it look like when used in a real system?

• Why I chose OAuth2 + OIDC—and not SAML—for my real web app (CSL) implemented architecture?

---

The Core Differences (High-Level)

Before diving into flows and code, it helps to anchor each technology to its true purpose:

• 

  OAuth2 → delegated authorization

• OIDC → authentication (identity) built on OAuth2

• SAML → enterprise SSO protocol (authentication + attributes)

A useful mental model:

OAuth2 answers “what is this app allowed to do?”
OIDC answers “who is this user?”
SAML answers “can this enterprise user access this system?”

---

OAuth2: Delegated Authorization

What OAuth2 Is (and Is Not)

OAuth2 is not an authentication protocol.
It does not define users, logins, or identity.

OAuth2 defines how a client obtains an access token that grants permission to call an API on someone else’s behalf.

Real-World OAuth2 Example

Imagine CSL needs to call a government API to fetch teaching schedules.

The teacher logs in once, consents, and CSL receives an access token.

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE
&client_id=CSL_APP
&client_secret=SECRET
&redirect_uri=https://csl.example.com/callback

Response:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "schedule.read"
}

CSL uses this token to call the API:

GET /api/schedules
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

What OAuth2 Does Well

• Secure API access

• Fine-grained scopes

• Machine-to-machine authorization

• Delegation without sharing passwords

What OAuth2 Does Not Do

• Define who the user is

• Standardize identity claims

• Guarantee authentication semantics

This is why OAuth2 alone is insufficient for login systems.

---

OpenID Connect (OIDC): Authentication on Top of OAuth2

What OIDC Adds

OIDC layers identity on top of OAuth2 by introducing:

• ID Tokens (standardized JWTs)

• User identity claims

• Nonce-based replay protection

• UserInfo endpoint

• Well-known discovery

In short:

OIDC turns OAuth2 into a login system.

Real-World OIDC Example (CSL Login)

In CSL, when a teacher clicks “Login with Government Identity”:

1. The browser is redirected to /authorize with scope=openid

2. The IdP authenticates the teacher

3. CSL receives an authorization code

4. CSL exchanges it for tokens

Response:

{
  "access_token": "...",
  "id_token": "eyJhbGciOiJSUzI1NiIs...",
  "expires_in": 900
}

Decoded id_token:

{
  "iss": "https://idp.example.gov",
  "sub": "teacher-98231",
  "aud": "CSL_APP",
  "email": "linh.nguyen@example.gov",
  "name": "Nguyen Van A",
  "exp": 1733683200
}

CSL then:

• validates the token

• maps sub to a local user

• creates a PHP session

• discards the token from frontend exposure

Why OIDC Fits Modern Systems

• Standardized identity model

• JWT-based, API-friendly

• Mobile- and SPA-compatible

• Works well with microservices

• Easy integration with modern IdPs

OIDC is why “Login with Google” works everywhere today.

---

SAML: Enterprise Identity Federation

What SAML Is

SAML (Security Assertion Markup Language) is an XML-based identity federation protocol created long before OAuth2.

It focuses on:

• enterprise SSO

• centralized identity providers

• strong trust relationships

• browser-based authentication

SAML does not use tokens or APIs the way OAuth2/OIDC does.

Real-World SAML Example

A university employee accesses an internal HR portal.

Flow:

1. User accesses the app

2. App redirects to enterprise IdP

3. IdP authenticates user

4. IdP sends a signed XML assertion back via POST

5. App validates the assertion and creates a session

Example SAML assertion (simplified):

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>teacher-98231</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>linh.nguyen@example.gov</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Strengths of SAML

• Extremely mature

• Widely used in enterprises

• Strong trust guarantees

• Well-suited for internal corporate apps

Weaknesses of SAML

• XML complexity

• Harder to debug

• Poor mobile and SPA support

• Not API-friendly

• Heavy configuration burden

SAML shines in closed enterprise environments—but struggles in modern web architectures.

---

Side-by-Side Comparison

---

Why CSL Chose OAuth2 + OIDC (Not SAML)

CSL needed:

• modern API-based identity

• government IdP compatibility

• clean backend integration

• no XML parsing

• CDN compatibility

• session-based PHP architecture

• future extensibility

OIDC delivered all of this.

SAML would have:

• increased complexity

• limited extensibility

• made API access harder

• conflicted with modern cloud-native patterns

---

How All Three Can Coexist

In many organizations:

• SAML handles internal enterprise SSO

• OIDC handles external apps and APIs

• OAuth2 handles service-to-service access

They are not mutually exclusive—they’re layered tools.

---

Choosing the Right One: Practical Guidance

Use OAuth2 if:

• you’re securing APIs

• users are not involved

• services need delegated access

Use OIDC if:

• users need to log in

• modern apps or mobile clients are involved

• you want standardized identity claims

Use SAML if:

• you’re integrating with legacy enterprise IdPs

• browser-only apps

• corporate intranets

• government systems that mandate it

---

Final Thoughts

OAuth2, OIDC, and SAML are not competing technologies—they’re solutions to different problems that emerged at different times. Understanding why each exists makes choosing between them straightforward.

In CSL, OAuth2 provided the authorization foundation, OIDC delivered modern identity, Redis-backed sessions ensured secure local control, and CloudFront signed cookies extended authorization to the CDN layer. Together, they formed a cohesive system that balances modern standards with real-world constraints.