✳ Learning path / 3 lessons
OAuth 2.0, OIDC, and SAML federation security
Three core lessons and one protocol deep dive cover delegated API authorization and enterprise Single Sign-On: separating the four OAuth 2.0 roles and Resource Server token checks, mapping signed OIDC/SAML claims to least-privilege roles via immutable (iss, sub) keys, and defending against the five federation failure modes.
Work through the lessons in order to build a complete engineering mental model, or jump straight to the topic you are designing or reviewing today. Electives sit beside the core lesson they extend and are not required to complete the path.
01Who holds the ticket: OAuth 2.0 roles and bearer token verification
An OAuth 2.0 access token is a scoped capability ticket presented by a client to a resource server. Separate the four OAuth roles and trace how a resource server validates issuer, audience, and expiry.
OAuth 2.0 Authorization Code + PKCE: front channel vs back channel
Step-by-step protocol trace of the OAuth 2.0 Authorization Code flow with PKCE, state, issuer validation, and back-channel token exchange. Why does OAuth 2.0 deliver a short-lived authorization code through the browser instead of the access token? Trace state, issuer, redirect URI, client authentication, and PKCE.
OIDC and SAML assertions: signed identity claims are not admin permission
An OpenID Connect ID Token or SAML 2.0 assertion proves that an Identity Provider authenticated a subject. It does not automatically make that subject an administrator.
Federation failure modes: five ways SSO and token trust break
When a Relying Party skips a signature, issuer, audience, time, or account-link check, one forged or replayed assertion can sign an attacker in. Five failure modes cover those skipped checks.
Test your engineering judgment
Every lesson closes with a 4-choice scenario check modeled on real architectural trade-offs. Ready for full hands-on simulations or certification drills?
Open the practice labs ↗ · Launch the CISSP practice simulator ↗