Domain 5 Β· Lesson 2 of 5

SSO, Federation & Identity Protocols

Đăng nhαΊ­p Mα»™t lαΊ§n & Giao thα»©c Danh tΓ­nh

SSO Protocol Comparison

Protocol Purpose Format Use Case TS Relevance
Kerberos AuthN β€” ticket-based Proprietary tickets Windows Active Directory Internal service (rare)
SAML 2.0 AuthN β€” browser SSO XML assertions Enterprise web apps Admin portal SSO potential
OAuth 2.0 AuthZ delegation JSON + HTTP API access grants Platform C uses JWT Bearer tokens
OIDC AuthN (on top of OAuth) JWT (ID Token) Modern app SSO "Login with Google" pattern

Kerberos Flow

Client

β†’ AS β†’

TGT

Ticket Granting Ticket

β†’ TGS β†’

Service Ticket

β†’

Service

  • KDC (Key Distribution Center) = AS (Authentication Server) + TGS (Ticket Granting Server)
  • Single point of failure: if KDC goes down, all Kerberos authentication fails
  • Tickets are time-limited (default 10 hours) β€” prevents replay attacks but requires clock sync (NTP)

OAuth 2.0 vs OIDC β€” Critical Distinction

OAuth 2.0 = AUTHORIZATION

Answers: "What can this app access?"

Delegates access to resources. Issues access tokens (opaque or JWT). Does NOT tell you who the user is β€” no identity claims.

OIDC = AUTHENTICATION (on top of OAuth)

Answers: "Who is the user?"

Adds an ID Token (JWT) with user claims: sub, email, name, iss, aud, exp. Used for "Login with Google/GitHub."

Federated identity: IdP (Identity Provider) authenticates the user. SP (Service Provider) relies on the IdP's assertion. JIT (Just-In-Time) provisioning: user account is created automatically on first SSO login.

JWT Structure & Security Risks

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxNjk5OTk5OTk5fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

header (red) . payload (yellow) . signature (green)

JWT payload is BASE64-ENCODED β€” NOT encrypted!

Anyone can decode the payload. The signature (using the private key) proves integrity, not confidentiality. Never put sensitive secrets in JWT payload.

JWT Security Attacks

AttackWhat HappensDefense
alg=none Attacker changes alg header to "none" β€” server accepts unsigned token Hardcode accepted algorithm to RS256; reject any other value
Key Confusion If RS256 server, attacker uses RSA public key as HMAC secret for HS256 signing Never accept HS256 when configured for RSA; validate alg on every request
Missing exp Expired token accepted because server doesn't validate exp claim Always validate exp β€” reject tokens past expiry
Missing aud Partner A token accepted by Partner D service β€” cross-tenant token abuse Validate aud claim matches the service receiving the token

Key Terms

Kerberos KDC TGT SAML IdP SP OAuth 2.0 OIDC JWT ID Token Federated Identity JIT Provisioning alg=none
Exam Tips
  1. OAuth 2.0 = AUTHORIZATION (not authentication). OIDC adds authentication on top via the ID Token.
  2. SAML = enterprise browser SSO (XML); OIDC = modern API/mobile (JWT). On the exam: mobile app SSO = OIDC.
  3. Kerberos KDC = single point of failure β€” if KDC goes down, authentication fails for entire domain.
  4. JWT payload is BASE64-encoded β€” NOT encrypted β€” sensitive data should never go in JWT payload.
  5. alg=none attack: if server doesn't validate the algorithm header, an attacker can send an unsigned token that gets accepted.
Work Application β€” Platform C JWT Security Checklist
  1. Verify alg header is hardcoded to RS256 β€” reject none and HS256 (key confusion risk).
  2. Validate exp claim on every request β€” reject tokens past expiry.
  3. Validate aud claim β€” Partner A token must be rejected by Partner D service (prevents cross-tenant abuse).
  4. Validate iss claim β€” tokens must be from Platform C's own issuer only.
  5. Short-lived access tokens (15 min) + refresh token rotation β€” limits window of token theft exposure.
  6. Private RSA signing key stored only in Vault β€” rotation schedule documented and tested.

Practice Quiz

Q1. OAuth 2.0 vs OIDC β€” which protocol provides authentication (identity), and which provides authorization (access)?

β–Ό Reveal Answer
OIDC provides authentication (adds the ID Token with user identity claims on top of OAuth 2.0). OAuth 2.0 alone provides only authorization β€” it delegates access but doesn't identify who the user is.
Common exam trap: "I used OAuth to log in." No β€” you used OIDC, which is built on OAuth. OAuth 2.0 gives you an access token to call an API. OIDC adds the ID Token (a JWT) that tells you who the user is (sub, email, name). If an exam question says "which protocol authenticates the user for SSO," the answer is OIDC (or SAML).

Q2. A developer decodes a JWT and reads the user's email and role from the payload. Should they trust this data for authorization decisions?

β–Ό Reveal Answer
Only if the signature is verified. The payload is BASE64-encoded (not encrypted) β€” anyone can decode and modify it. The RSA signature proves the payload hasn't been tampered with. Always verify signature first before trusting claims.
JWT payload is just base64url-encoded JSON β€” not encrypted, not secret. An attacker can modify the payload and re-encode it. The only thing preventing this is the signature, which requires the private key. Always validate the signature, then validate exp, aud, and iss before using any claims for authorization.

Q3. A Kerberos KDC experiences a hardware failure at 9am on a business day. What is the immediate impact?

β–Ό Reveal Answer
All Kerberos-based authentication fails. Users cannot log in to any system that relies on Kerberos (entire Active Directory domain). This is the single point of failure risk of Kerberos.
The KDC is both the AS (Authentication Server) and TGS (Ticket Granting Server). If it fails, no new Kerberos tickets can be issued. Users with existing tickets may continue working until tickets expire (default 10 hours), but no new logins succeed. Mitigate with a secondary (backup) KDC.

Q4. What is the alg=none attack in JWT, and what configuration prevents it?

β–Ό Reveal Answer
The alg=none attack: attacker changes the JWT header to "alg": "none" β€” if the server accepts any algorithm the token claims, it accepts an unsigned token with no verification. Defense: server must hardcode which algorithm it accepts (e.g., RS256 only) and reject any token claiming a different algorithm.
JWT libraries historically had a vulnerability where they would check the alg header first and then use that algorithm β€” including "none" (no signature). Fix: never let the token dictate the algorithm. The server knows what algorithm it uses; validate only against that hardcoded value. This is a classic JWT implementation flaw tested on CISSP.

Q5. A mobile app needs SSO β€” the user logs in and the app receives identity information (name, email) plus a token to call APIs. Which protocol combination should be used?

β–Ό Reveal Answer
OIDC (for authentication / ID Token with user identity claims) + OAuth 2.0 (for the access token to call APIs). Not SAML β€” SAML is XML-based and browser-redirect focused, poorly suited to mobile apps.
SAML 2.0 relies on browser redirects and XML β€” it works in enterprise web apps but is difficult to implement in native mobile apps. OIDC was designed for exactly this use case: mobile and API-first applications. OIDC gives an ID Token (who the user is) and an access token (what they can do). On the exam: "mobile SSO" = OIDC; "enterprise web app SSO" = SAML or OIDC.
← Lesson 1: Authentication Lesson 3: Access Control Models β†’