How It Works — Trust

Behind every login, every token exchange, every encrypted channel, there is a concrete sequence of steps — a flow. This chapter walks through the flows that establish trust, played frame by frame.

Trusted Third Party [Trusted Party] {1}

The idea underneath every token, JWT, and federation scheme: a party both sides trust vouches for who someone is.

Proving Origin Through a Trusted Third Party [Trusted Party] {1}

Signed Messages — Proving Origin and Integrity [Signature] {1}

JWT — Standardizing Signed Messages [JWT] {1}

Refresh Tokens — Renewing an Expired Access Token [Refresh] {1}

Encryption [Encryption] {1}

Every later flow assumes secrets can cross the network safely. These flows show how — shared keys, key pairs, agreeing on a key in the open, and combining approaches for real traffic.

Symmetric Encryption — One Shared Key [Symmetric] {1}

Asymmetric Encryption — Public Key Locks, Private Key Unlocks [Asymmetric] {1}

Diffie-Hellman — Agreeing on a Secret in the Open [Diffie-Hellman] {1}

Hybrid Encryption — Asymmetric to Share a Key, Symmetric for the Data [Hybrid] {1}

Authentication [Authentication] {1}

Proving a human is who they claim to be. Passwords open the section; second factors — one-time codes, hardware keys, passkeys — each close an attack the previous one left open.

Password Signup — Creating an Account [Password Signup] {1}

Password Login — Checking a Password and Setting a Session Cookie [Password Auth] {1}

MFA With an Authenticator App — TOTP [MFA TOTP] {1}

MFA by SMS — Codes Sent Through the Phone Network [MFA SMS] {1}

MFA With WebAuthn — Signing a Challenge [MFA WebAuthn] {1}

Passkeys — Public-Key Login That Replaces the Password [Passkeys] {1}

Identity Federation [Identity Federation] {1}

Instead of every site holding its own passwords, one Identity Provider vouches for a user. These flows show the two ways to carry that trust — signatures and lookups — and how OIDC, SAML, SSO, and Kerberos put them to work.

Federation by Signature — The Pattern [Federation by Signature] {1}

Federation by Lookup — The Pattern [Federation by Lookup] {1}

OpenID Connect — Federation by Signature, Modern (JWT) [OIDC] {1}

SAML 2.0 — Federation by Signature, Legacy (XML) [SAML] {1}

SSO Pattern — Single Session on the IdP [SSO] {1}

Kerberos [Kerberos] {1}

Workload Identity [Workload Identity] {1}

The same problem as human authentication, but for services. These flows go from static shared credentials to certificates, and finally to cloud-native identity where the platform itself vouches.

Static Credentials — the Workload's Shared Password [Static Credentials] {1}

mTLS — Services Proving Each Other With Certificates [mTLS] {1}

Cloud Workload Identity — the Platform Vouches for the Service [Workload Identity] {1}

Access Federation [Access Federation] {1}

Once identity is settled, the next step is delegation and inter-service trust — a user letting one app act on their behalf at another, or two services proving each other on the wire.

OAuth2 — Implicit (legacy) [OAuth2 Implicit] {1}

OAuth2 — Auth Code without PKCE [OAuth2 No PKCE] {1}

OAuth2 — Auth Code + PKCE [OAuth2 PKCE] {1}

OAuth2 — Client Credentials [Client Credentials] {1}

mTLS Handshake [mTLS Handshake] {1}

Service Mesh Sidecar [Service Mesh] {1}

CLI Delegation [CLI] {1}

Terminal tools have no browser popup, no callback URL, and no session cookie. These flows show the tricks command-line clients use to obtain a token — running a tiny local server, polling for a code, or shelling out to a plugin.

OAuth Loopback Redirect — Logging In Through the Local Browser [Loopback] {1}

OAuth2 — Device Flow [Device Flow] {1}

Personal Access Token — A Long-Lived Bearer [PAT] {1}

Exec Credential Plugin — A CLI That Shells Out for a Token [Exec Plugin] {1}