3 lessons

OAuth & OIDC

Delegated authorization, the authorization code flow with PKCE, and the identity layer on top — with the "OAuth is not login" distinction taken seriously.

Asset→Threat→Attack Surface→Trust Boundary→Vulnerability→Exploit Path→Impact→Mitigation→Defense in Depth→Residual Risk

Every lesson below identifies the asset, attacker capability and boundary before naming the vulnerability. Controls are split into prevention, detection and recovery; residual risk is explicit.

OAuth 2.x — Delegated Authorization

▶ lab

A protocol for letting an application act on a user's behalf against a third-party API without ever holding the user's password — which is a different problem from logging users into your own site.

Boundary · Three-way: between the user and the client, between the client and the authorization server, and between the client and the resource server — each with a different thing being proven.

The Authorization Code Flow (with PKCE)

▶ lab

The flow that keeps tokens off the front channel: the browser carries only a one-time code, which the client exchanges for tokens over a back channel — with PKCE proving that the exchanging party is the one that started the request.

Boundary · The split between the **front channel** (through the user's browser, observable and manipulable) and the **back channel** (direct server-to-server, authenticated and private).

OpenID Connect

▶ lab

OAuth plus an identity layer: an ID token issued to your client, signed by the provider, containing verified claims about who the user is — which is the piece OAuth deliberately does not provide.

Boundary · The boundary between the identity provider's assertion and your application's session — crossed exactly once, at login, and absolutely dependent on correct verification.