The Identity Stack, Episode 10
EP09: Active Directory → EP10 → EP11: Identity Providers → …
Focus Keyphrase: SAML vs OIDC explained
Search Intent: Investigational
Meta Description: SAML, OAuth2, and OIDC solve different problems and are often confused. Here’s what each protocol does, when to use it, and how a browser SSO login actually works. (163 chars)
TL;DR
- SAML 2.0 is a federation protocol for browser-based SSO — an IdP issues a signed XML assertion that a Service Provider trusts; designed for enterprise applications
- OAuth2 is an authorization delegation protocol, not authentication — it lets an application act on your behalf without knowing your password; the access token says what, not who
- OIDC (OpenID Connect) = OAuth2 + an identity layer — adds the
id_token(a JWT containing who you are) on top of OAuth2’saccess_token(what you can do) - SAML vs OIDC: SAML is XML, enterprise-native, stateful; OIDC is JSON/JWT, API-native, stateless — new applications almost always use OIDC
- The
id_tokenis a JWT — decode it at jwt.io and read every claim — it tells you exactly what the IdP asserts about the user - The browser SSO flow is three redirects: user → SP → IdP (authenticate) → SP (consume assertion)
The Problem: LDAP and Kerberos Don’t Cross the Internet
EP09 showed how authentication works inside a corporate network. LDAP and Kerberos both assume network proximity to the directory server — firewall-friendly ports don’t help when the authentication protocol requires a direct connection to the KDC or directory.
Internal network: works
Browser → intranet app → LDAP/Kerberos → AD DC (all on 10.0.0.0/8)
Internet: breaks
Browser → SaaS app (AWS) → LDAP/Kerberos → AD DC (on-prem behind firewall)
✗ KDC not reachable across NAT
✗ LDAP not exposed to internet (shouldn't be)
✗ Every SaaS app can't have its own LDAP connection to your DC
SAML was invented in 2002 to solve this. OIDC in 2014. Both let identity assertions travel over HTTPS — the one protocol that crosses every firewall.
SAML 2.0: Enterprise Browser SSO
SAML 2.0 has three actors: the User, the Identity Provider (IdP), and the Service Provider (SP).
1. User visits SP (e.g., Salesforce)
SP: "I don't know this user — send them to the IdP"
↓ HTTP redirect with SAMLRequest (base64-encoded AuthnRequest)
2. User arrives at IdP (e.g., Okta, AD FS, Entra ID)
IdP: "Authenticate me" → user enters credentials
IdP: generates a signed SAML Assertion (XML)
↓ HTTP POST to SP's Assertion Consumer Service (ACS) URL
3. SP receives the SAMLResponse
SP: verifies the signature using IdP's public key
SP: extracts user attributes from the Assertion
SP: creates a session — user is logged in
The SAML Assertion is an XML document signed by the IdP. It contains:
<saml:Assertion>
<saml:Issuer>https://idp.corp.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
[email protected]
</saml:NameID>
</saml:Subject>
<saml:Conditions
NotBefore="2026-04-27T01:00:00Z"
NotOnOrAfter="2026-04-27T01:05:00Z"> ← short-lived: replay protection
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>[email protected]</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="groups">
<saml:AttributeValue>engineers</saml:AttributeValue>
<saml:AttributeValue>sre-team</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
The SP trusts the assertion because it’s signed with the IdP’s private key, and the SP has the IdP’s public certificate configured. No direct connection between SP and IdP needed during authentication — only the browser carries the assertion.
SP-initiated vs IdP-initiated:
– SP-initiated: user visits the SP, gets redirected to IdP, authenticates, redirected back — the common flow
– IdP-initiated: user starts at the IdP (e.g., company portal), clicks an app, IdP sends assertion directly — simpler but no SP-generated RequestID, so the SP can’t verify the request was expected (a security concern)
OAuth2: Authorization Delegation (Not Authentication)
This distinction is important and consistently confused: OAuth2 is for authorization, not authentication.
OAuth2 solves: “I want to let GitHub Actions post to my Slack without giving GitHub my Slack password.”
Resource Owner (you) → grants permission to → Client (GitHub Actions)
│
│ access_token
▼
Resource Server (Slack API)
"this token can post messages"
The access_token answers “what can this client do?” not “who is this user?” A resource server receiving an access token knows the token is valid and what scopes it carries — it does not necessarily know which human authorized it.
The four OAuth2 grant types:
| Grant | Use case |
|---|---|
| Authorization Code | Web apps (server-side) — most secure, recommended |
| PKCE (+ Auth Code) | Native/SPA apps — Auth Code without client secret |
| Client Credentials | Machine-to-machine (no user) — service accounts |
| Device Code | Devices without browsers (smart TVs, CLIs) |
The Implicit grant (tokens in URL fragment) is deprecated. Don’t use it.
OIDC: OAuth2 + Who You Are
OpenID Connect adds identity to OAuth2 by adding the id_token — a JWT that the IdP signs and that contains claims about the authenticated user.
Authorization Code flow with OIDC:
1. Client redirects user to IdP:
GET /authorize?
response_type=code
&client_id=myapp
&scope=openid email profile ← "openid" scope triggers OIDC
&redirect_uri=https://app.com/callback
&state=random-nonce
2. IdP authenticates user, returns:
GET /callback?code=AUTH_CODE&state=random-nonce
3. Client exchanges code for tokens:
POST /token
grant_type=authorization_code&code=AUTH_CODE...
4. IdP returns:
{
"access_token": "eyJ...", ← what the user authorized
"id_token": "eyJ...", ← who the user is (JWT)
"token_type": "Bearer",
"expires_in": 3600
}
The id_token decoded:
{
"iss": "https://idp.corp.com", ← issuer (the IdP)
"sub": "user-guid-12345", ← subject (stable user identifier)
"aud": "myapp", ← audience (your client_id)
"exp": 1745730000, ← expiry (Unix timestamp)
"iat": 1745726400, ← issued at
"email": "[email protected]",
"name": "Vamshi Krishna",
"groups": ["engineers", "sre-team"] ← custom claims from IdP
}
# Decode any JWT at the command line (no verification — for debugging only)
echo "eyJ..." | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Or: jwt.io — paste the token, read every claim
sub is the stable user identifier. Email addresses change. Names change. The sub claim is the IdP’s internal identifier for the user — use it as the primary key when storing user data. Never store email as the primary key.
SAML vs OIDC: When to Use Which
| SAML 2.0 | OIDC | |
|---|---|---|
| Format | XML | JSON / JWT |
| Transport | HTTP POST (browser only) | HTTP redirect + JSON API |
| Age | 2002 | 2014 |
| Enterprise adoption | Very high (AD FS, Okta, Entra ID) | Very high (newer apps) |
| API-friendly | No | Yes |
| Mobile apps | No | Yes |
| Complexity | High (XML, schemas, signatures) | Medium (JWT, JSON) |
| Single Logout | Specified (rarely works well) | Optional, inconsistent |
Use SAML when: You’re integrating with an enterprise SaaS that only supports SAML (Salesforce classic, legacy HR systems), or your IdP team mandates it.
Use OIDC when: You’re building a new application, integrating with a modern IdP, or need API-based token validation. OIDC is the default for everything new.
Use OAuth2 (Client Credentials) when: Service-to-service authentication with no user — your CI/CD pipeline authenticating to an API, your microservice calling another microservice.
A Complete Browser SSO Flow (OIDC)
1. User visits https://app.corp.com (not logged in)
App: no session → redirect to IdP
2. GET https://idp.corp.com/authorize?
response_type=code
&client_id=app-corp
&scope=openid email
&redirect_uri=https://app.corp.com/callback
&state=abc123
&nonce=xyz789
3. IdP: user is not authenticated → show login form
User: enters [email protected] + password
(or: IdP sees existing session cookie → skip login)
4. IdP: authentication success
Redirect: GET https://app.corp.com/callback?code=AUTH_CODE&state=abc123
5. App (server-side): validate state=abc123 (CSRF protection)
POST https://idp.corp.com/token
grant_type=authorization_code
&code=AUTH_CODE
&client_id=app-corp
&client_secret=SECRET
&redirect_uri=https://app.corp.com/callback
6. IdP responds:
{ "id_token": "JWT...", "access_token": "JWT...", "expires_in": 3600 }
7. App: validate id_token signature (using IdP's JWKS endpoint)
App: extract sub, email, groups from id_token
App: create session for [email protected]
App: redirect user to original destination
Step 7 is where most bugs live. The app must validate: signature (using IdP’s public keys from /.well-known/jwks.json), iss (matches the expected IdP), aud (matches the client_id), exp (not expired), and nonce (matches what was sent in step 2). Skip any of these and you have an authentication bypass.
⚠ Common Misconceptions
“OAuth2 is for login.” OAuth2 is for authorization delegation. It can be used as a login mechanism only when OIDC (the openid scope + id_token) is added on top. “Login with Google” uses OIDC, not bare OAuth2.
“JWTs are encrypted.” By default, JWTs are signed (JWS), not encrypted. The header and payload are base64url-encoded — anyone can decode them. Encryption (JWE) is a separate, less commonly used spec. Never put secrets in a JWT payload assuming it’s private.
“SAML Single Logout works reliably.” SAML SLO is specified but inconsistently implemented. Many SPs ignore SLO requests or don’t propagate them correctly. Don’t depend on SLO for security — session revocation requires additional mechanisms (short-lived tokens, token introspection, session registries).
Framework Alignment
| Domain | Relevance |
|---|---|
| CISSP Domain 5: Identity and Access Management | SAML, OAuth2, and OIDC are the three protocols that enable federated identity and SSO — understanding which does what is foundational to modern IAM design |
| CISSP Domain 4: Communications and Network Security | JWT validation (signature, claims, expiry) is a network security control — failing to validate any claim is an authentication bypass vulnerability |
| CISSP Domain 3: Security Architecture and Engineering | The choice of SAML vs OIDC is an architectural decision that affects every application integration, mobile support, and API design |
Key Takeaways
- SAML 2.0: XML-based browser SSO — three redirects, signed assertion, enterprise legacy apps
- OAuth2: authorization delegation — access tokens grant scopes, not identity
- OIDC: OAuth2 +
id_token— adds who the user is on top of what they can do subis the stable user identifier in OIDC — never use email as a primary key- JWT validation must check: signature,
iss,aud,exp,nonce— missing any is a security bypass - New applications: OIDC. Legacy enterprise SaaS: SAML. Service-to-service: OAuth2 Client Credentials
What’s Next
EP10 covered the protocols. EP11 covers the systems that implement them — the identity providers: what Okta, Entra ID, Keycloak, and AD FS actually do, how they federate with each other, and how SCIM handles user provisioning separately from authentication.
Next: Identity Providers Explained: On-Prem, Cloud, SCIM, and Federation
Get EP11 in your inbox when it publishes → linuxcent.com/subscribe
