TECHNICAL PRESENTATION · SERIES PRIMER — READ FIRST

Identity & Authorisation
A Primer

Sixty years of asking "who are you?" and "what may you do?" — and how we got here
No code No RFCs in the body The whole field on one map ~20 minutes
🪪 who 🔑 prove 📜 may 📑 audit

The gateway deck for the Identity & Access and Authorisation series. Why these problems exist, the four eras of the field, the threat landscape, the standards lineage, and a roadmap to every other deck.

Story  ·  Vocabulary  ·  Map  ·  Roadmap
01

Topics

The story

  • Why identity exists at all — the original multi-user problem
  • AuthN vs AuthZ — the defining pair, separated
  • Four eras: mainframe → web → mobile/cloud → agent & wallet
  • The threat landscape that shaped each era's primitives

The vocabulary

  • Principal · credential · token · scope · audience · claim
  • IdP · RP · PEP · PDP · PIP · PAP — the alphabet soup, decoded
  • North-south vs east-west — the two axes of authorisation
  • Federation, delegation, impersonation — the three confusing words

The map

  • Standards landscape — IETF / OIDF / OASIS / W3C / FIDO / NIST / CNCF
  • The AuthN conceptual map — methods, federation, workload identity
  • The AuthZ conceptual map — RBAC → ABAC → ReBAC, engines, topologies
  • Build vs buy — IDaaS providers vs open source vs roll-your-own

The roadmap

  • The legal & regulatory backdrop driving the next five years
  • How the eleven decks in this series fit together
  • A reading order: where to start by role and by goal
  • Three sentences you can screenshot and quote
02

Why Identity Exists at All — The Original Problem

A computer for one user has no need for identity. The moment a second user shares the machine — or the network — three problems appear at once: tell us apart, limit the damage we can do to each other, and have a record of who did what. Every spec in this field — passwords, Kerberos, SAML, OAuth, OIDC, SPIFFE, OPA, MCP — is an attempt to solve one of those three problems for a particular topology.

Single user no identity needed (home computer, calculator) + second user 1. Tell us apart → Authentication (AuthN) 2. Limit damage we can do → Authorisation (AuthZ) 3. Record who did what → Audit / non-repudiation passwords · passkeys · SAML · OIDC scopes · RBAC · ABAC · ReBAC · OPA syslog · CAEP · SSF · audit pipelines Saltzer & Schroeder, 1975: "least privilege" and "fail-safe defaults" already named all three. We've been building tools to honour them ever since.
03

The Defining Pair — AuthN vs AuthZ

Authentication (AuthN) — "who are you?"

  • Input: a credential — password, OTP, biometric, signing key, certificate
  • Output: a verified claim — "this principal is alice@example.com" (or "this workload is spiffe://prod/orders")
  • Failure mode: impersonation — someone proves to be you who isn't
  • Standards owners: FIDO Alliance, IETF, W3C, OIDF, NIST

Authorisation (AuthZ) — "what may you do?"

  • Input: the verified principal + an action + a resource + (often) context (time, IP, risk score)
  • Output: a binary decision — permit / deny — plus an audit-ready reason
  • Failure mode: privilege escalation — doing something you weren't permitted to do
  • Standards owners: OASIS (XACML), CNCF (OPA, OpenFGA), AWS / GCP / Azure (cloud IAM), Cedar (Amazon)

Three concepts that live between them

  • Federation — one IdP authenticates, many RPs trust the result. SAML, OIDC, OpenID Federation 1.0.
  • Delegation — Alice lets an app act on her behalf with a narrowed scope. OAuth's whole reason for existing.
  • Impersonation — a service acts as a user (lossless). Token Exchange (RFC 8693). Logged carefully.

Why the confusion is fatal

Many real incidents — Capital One 2019, Optus 2022, Microsoft Storm-0558 2023 — start because someone treated "the request authenticated successfully" as if it implied "the request was authorised". It does not. They are different decisions, computed by different code, often by different teams, against different policy sources.

Memorable rule

"AuthN is the bouncer at the door. AuthZ is the wristband that says which rooms you can enter. Audit is the CCTV that says where you actually went."

04

A Brief History I — The Mainframe & Network Era (1961-1995)

The first thirty years are the story of moving identity from "a file on this machine" to "a service trusted across many machines". Every primitive we still use — shared secret, ticket, directory, certificate — was invented here.

1961 1995 1961 CTSS first password file 1975 Saltzer & Schroeder least privilege · fail-safe 1978 Needham-Schroeder tickets, replay attacks 1988 Kerberos v4 (MIT) trusted third party at scale 1993 LDAP / X.500 directory as a service 1994 SSL 2.0 (Netscape) credentials over public web 1995 Win NT / DC enterprise SSO arrives

What was solved

"Tell users on this system apart" → "tell users on this network apart" via tickets and shared secrets.

What hadn't been

Identity across organisations. Each company was its own island; trust did not cross boundaries.

Primitives still in use

Password hash, ticket, directory entry, CA-issued certificate, the principal as a first-class object.

05

A Brief History II — The Web & Federation Era (1995-2014)

The web made every company a service for every user on Earth. Federation — "I trust your IdP to vouch for who this is" — became the dominant model. SAML solved enterprise SSO; OAuth solved the password-sharing problem; OpenID Connect bolted identity back onto OAuth.

1995 2014 2002 SAML 1.0 XML federation 2005 SAML 2.0 enterprise SSO standard 2007 OAuth 1.0 stop sharing passwords 2010 JWT (Internet-Draft) signed JSON tokens 2012 OAuth 2.0 (RFC 6749) bearer tokens, grant types 2013 SCIM 2.0 cross-org user provisioning 2014 OIDC Core 1.0 "Sign in with Google"

What was solved

Identity across organisations. Users sign in once at their IdP and reach hundreds of relying parties.

What hadn't been

Phishing-resistant credentials, mobile-first flows, machine-to-machine identity, anti-replay token binding.

Primitives still in use

SAML assertion, JWT, OAuth grant types, scopes, the IdP / RP / Resource-Server triad, SCIM as the provisioning standard.

06

A Brief History III — Mobile, Cloud & Zero Trust (2014-2023)

Phishing went industrial; the perimeter dissolved; workloads multiplied a hundred-fold under Kubernetes. The era's signature is "trust nothing — verify the credential, the device, the workload, every time". FIDO2/passkeys finally beat phishing; SPIFFE solved workload identity; OPA gave authorisation a programmable language.

2014 2023 2014 FIDO U2F · BeyondCorp phishing-resistant · "Zero Trust" 2015 PKCE (RFC 7636) OAuth for mobile/SPAs 2018 SPIFFE/SPIRE · OPA workload identity · Policy-as-Code 2019 WebAuthn L1 · NIST 800-207 passkey foundation · ZT architecture 2021 Zanzibar paper · OpenFGA ReBAC at planet scale 2022 Passkeys (sync) Apple/Google/MS commit 2023 DPoP · Cedar · OAuth 2.1 sender-bound tokens · ABAC

What was solved

Phishing (passkeys), workload-to-workload identity (SPIFFE), policy as code (OPA / Rego), mobile-safe OAuth (PKCE).

What hadn't been

User-controlled identity (your wallet, not the IdP's database). AI agents acting on your behalf. Cross-border, cross-trust-domain federation at country scale.

Primitives still in use

WebAuthn credential, X.509 SVID, OPA bundle, Cedar policy, the policy-decision-point pattern, mTLS-everywhere east-west.

07

A Brief History IV — The Agent & Wallet Era (2024-now)

Two simultaneous shifts. Wallets: the EU mandates that every citizen has a state-issued digital identity wallet by 2026 — identity moves from "row in an IdP database" to "a credential I hold and present". Agents: AI systems become first-class principals — they hold tokens, call APIs on the user's behalf, and need their own audit trail. The MCP authorisation profile is the early canonical answer.

2024 2026 2024-05 eIDAS 2.0 enacted EUDI Wallet mandated 2024-09 OpenID Federation 1.0 trust chains for SIOPv2 2024-11 MCP launched agents need authorisation 2025-06 MCP authz profile OAuth + Resource Indicators 2025-Q4 FAPI 2.0 final finance-grade OIDC baseline 2026-08 EU AI Act enforced agent identity & audit 2026-Q4 EUDI Wallet live all 27 member states

What's being solved

Citizen-controlled identity. Selective disclosure (prove you're over 18 without revealing your date of birth). Agent delegation with a paper trail.

What's still open

Cross-jurisdiction wallet trust, agent liability models, agent-to-agent delegation, the regulator's audit grammar for AI systems.

New primitives

Verifiable Credential, mDoc, SIOPv2 wallet, OpenID4VCI/VP, agent-as-principal, MCP-resource audience, signed agent action logs.

08

The Threat Landscape — What All These Specs Defend Against

Every protocol decision in the field — DPoP, audience binding, PKCE, FAPI, mTLS east-west, SPIFFE federation — answers a specific attack class. If you understand which attacks shape which mitigations, the protocol zoo collapses into a small number of obvious moves.

Threat What it means in practice Defence(s) Where it's covered
Phishing User typed a real password into a fake login page WebAuthn / passkeys (origin-bound) Authentication Methods
Credential stuffing Leaked password + bot tries it on every site Argon2id, breach lookups (HIBP), rate limit, MFA Authentication Methods
Token theft & replay Bearer JWT exfiltrated → attacker uses it DPoP, mTLS-bound tokens, short TTL, refresh rotation Adv. OIDC · Edge AuthZ
Confused deputy Token meant for service A used at service B Resource Indicators (RFC 8707), audience claim, Token Exchange downscope OAuth · OIDC · Edge AuthZ
Lateral movement Attacker pivots across services after first compromise SPIFFE workload identity, mTLS east-west, ABAC at every hop Workload Identity AuthZ
Privilege escalation Authenticated user does what they shouldn't Least privilege, RBAC → ABAC → ReBAC, PDP central, audit Authorization Models
SAML XSW / alg confusion Forged assertion / "alg":"none" JWT accepted Strict signature validation, pinned algorithms, FAPI baseline SAML & SCIM · Adv. OIDC
Session hijack via subdomain XSS Cookie / token leaked from a less-secure subdomain HttpOnly, SameSite, scope cookies tightly, CSP, separate origins Authentication Methods
Supply-chain compromise Attacker patches your dependency / image / IaC Sigstore, SLSA, signed SBOMs, provenance attestation Cloud Security · Workload Identity
Agent prompt injection Hostile data steers an LLM agent to misuse a tool token Per-tool scoped tokens, resource audience, human-in-the-loop confirms, CAEP signals OAuth for MCP · Edge AuthZ
09

The Standards Landscape — Who Owns What

Identity is unusual among engineering domains in having many standards bodies, each owning a slice. Knowing which body owns which spec tells you where the vocabulary, the disputes, and the next revisions live.

BodyOwns
IETFOAuth 2.0/2.1, JWT (7519), DPoP (9449), Token Exchange (8693), PKCE (7636), PAR (9126), JAR (9101), Resource Indicators (8707), JWS / JWE
OIDFOpenID Connect Core, FAPI 1/2, Federation 1.0, SIOPv2, OpenID4VCI, OpenID4VP, SSF / CAEP, MODRNA, RISC
OASISSAML 2.0, XACML, WS-Security, WS-Federation
W3CWebAuthn (L3), Verifiable Credentials (VC 2.0), DIDs, CredentialManagement
FIDO AllianceU2F, FIDO2 / CTAP, MDS (metadata service), passkey UX guidance
BodyOwns
ISO/IECISO 18013-5/-7 (mDL), ISO/IEC 23220 (mobile eID), ISO 29115 (assurance)
NISTSP 800-63 (Digital Identity, IAL/AAL/FAL), SP 800-207 (Zero Trust), FIPS 201 (PIV)
CNCFSPIFFE/SPIRE, OPA / Rego, OpenFGA, Cilium, Falco
EU bodieseIDAS 2.0 (regulation), EUDI Wallet ARF (architecture & reference framework), GDPR / DORA
Vendor / cloudAWS IAM & Cedar, Google IAM & Zanzibar, Microsoft Entra, Apple/Google passkey ecosystems, Anthropic MCP authz profile

Reading the body tells you the politics

IETF specs are tight, narrow, often grumpy and security-driven. OIDF specs are profiles — they say "use these RFCs together, with these constraints". OASIS is enterprise / XML legacy. W3C and FIDO own the browser contract. NIST and ISO own the regulator's contract. Cloud vendors and CNCF projects move fastest but break compatibility.

10

The AuthN Conceptual Map

Factors knowledge → password, PIN, recovery possession → TOTP, push, passkey, smartcard inherence → fingerprint, face, voice ↳ NIST AAL1 / AAL2 / AAL3 Methods (modern) password + Argon2id + breach check TOTP / push (RFC 6238 / OOB) WebAuthn / FIDO2 / Passkey ↳ origin-bound, phishing-proof Federation protocols SAML 2.0 (enterprise legacy) OIDC + JWT (modern web/mobile) SCIM 2.0 (provisioning) ↳ OpenID Federation 1.0 (Sep 2024) Workload identity SPIFFE / SPIRE → SVIDs (X.509 or JWT) IRSA (AWS) · GCP WI · Azure WI · WIF K8s ServiceAccountTokenVolumeProjection ↳ no passwords for machines · attest, then trust User-held credentials (wallet era) SIOPv2 — wallet as the IdP OpenID4VCI / OpenID4VP — issue + present ISO mDL · Verifiable Credentials ↳ selective disclosure, no IdP phone-home Each row covered in detail by a deck: Authentication Methods · OAuth (Primer / Intro / MCP) · OIDC (Intro / Adv) · SAML & SCIM · Workload Identity AuthZ
11

The AuthZ Conceptual Map

Models — the arc DAC owner sets ACL MAC labels + clearances RBAC roles → permissions ABAC attrs + context ReBAC relationship tuples → each step adds context the previous couldn't express Engines — Policy-as-Code OPA / Rego general PDP, sidecar / library Cedar (AWS) analyzable, ABAC + RBAC OpenFGA / SpiceDB Zanzibar-style ReBAC Cloud IAM evaluators AWS/GCP/Azure proprietary Casbin embedded library Topologies — where the decision runs North-South — at the edge API GW, Envoy ext_authz, Cloudflare Access East-West — in the mesh Istio AuthorizationPolicy, Linkerd, Cilium In-app — in business code domain-aware checks, OPA library In the data — RLS / row-level Postgres RLS, Snowflake row-access policies Decks: Authorization Models · Workload Identity AuthZ · Edge & Gateway AuthZ
12

North-South vs East-West — The Two Axes

Once a request enters your system, every authorisation decision falls into one of two camps. They have different threat models, different latency budgets, different identity carriers, and almost always different teams owning them. Confusing the two is a top-three cause of edge bugs.

internet (untrusted) user / agent + JWT / cookie North-South Edge / API GW / Ingress The Edge validate JWT downscope token terminate mTLS propagate identity trust domain (mesh) · spiffe://prod/ api SVID orders SVID db SVID East-West mTLS · SVID · Istio AuthorizationPolicy

North-South — at the edge

  • Identity carrier: JWT / cookie / OAuth bearer / mTLS client cert
  • Threats: phishing, token theft, replay, confused deputy, scraping
  • Latency: ~5-30 ms acceptable; can call out to introspection
  • Decks: Edge & Gateway AuthZ, OAuth for MCP

East-West — inside the mesh

  • Identity carrier: SPIFFE SVID (X.509 or JWT), mesh mTLS
  • Threats: lateral movement, supply-chain compromise, blast-radius
  • Latency: sub-millisecond; decisions must be local (sidecar)
  • Decks: Workload Identity & Service-Mesh AuthZ
13

Build vs Buy — The Provider Landscape

Three options when you need identity for a product. The right answer is almost always "buy or use OSS"; the deeper question is which trade-off matches your cost model, compliance needs, and tolerance for vendor lock-in.

Buy — IDaaS

  • Auth0 · Okta · Microsoft Entra
  • Stytch · WorkOS · Clerk
  • AWS Cognito · Firebase Auth
  • FusionAuth · Descope

Best when: you need SOC 2 / FedRAMP inheritance fast, B2B SAML/SCIM out of the box, and login is not your differentiator. Cost scales per MAU.

Self-host — open source

  • Keycloak (Red Hat, Java)
  • ZITADEL (Go, OIDC + multi-tenant)
  • Authentik (Python, full IdP)
  • Ory (Hydra/Kratos/Keto, Go)
  • Authelia · Logto

Best when: data residency / sovereignty is a hard requirement, MAU economics break commercial, or you need deep customisation. You own the on-call.

Build — almost never

  • Roll-your-own SAML / OIDC: don't
  • Roll-your-own session cookies: maybe
  • Roll-your-own AuthZ inside business code: yes, but use OPA / Cedar / OpenFGA underneath

The trap: identity protocols look simple and aren't. Spend the first year on your product, not on JWT validation edge cases.

A useful split

AuthN + federation = buy. Login is largely a solved, commoditised, and highly-attacked surface — leverage someone whose only job is keeping it correct. AuthZ = build, on a policy engine. Authorisation is your business logic — what your users may do is unique to your product. Use a PDP (OPA / Cedar / OpenFGA), keep policies in your repo, and treat the engine as a library, not a product.

14

The Legal & Regulatory Backdrop

Almost every identity standard you'll meet exists because a regulator wrote a rule that needed wiring up. If you understand the regulation, you understand why the spec is shaped the way it is — and where the next standard is coming from.

RegulationForce dateWhat it requires (in identity terms)Standards / specs it produced
GDPR (EU) 2018-05 Lawful basis for processing PII; right to erasure; pseudonymous IDs preferred OIDC pairwise subjects, SCIM delete semantics, ID-token minimisation
PSD2 SCA (EU) 2019-09 Strong customer authentication for online payments; dynamic linking FAPI 1.0, then FAPI 2.0; OBIE / Berlin Group profiles
HIPAA (US) 2003 (still) Audit trail, MFA for PHI, BAA contracts; minimum necessary access SAML in healthcare, SMART on FHIR (OAuth profile)
CCPA / CPRA (CA) 2020 / 2023 Opt-out of sale, right to know, right to delete GPC header, SCIM delete cascade, identity-graph minimisation
eIDAS 2.0 (EU) 2024-05 Every citizen must be able to use a state-recognised digital wallet EUDI Wallet ARF, OpenID4VCI / VP, ISO mDL, SD-JWT
DORA (EU finance) 2025-01 Operational resilience; ICT third-party risk; incident reporting in hours FAPI 2.0 baseline, OpenID Federation 1.0 trust chains
EU AI Act 2026-08 Identity, log, and audit "high-risk" AI systems and their actions MCP authz profile, agent-as-principal patterns, signed action logs
SOC 2 / ISO 27001 continuous Access reviews, MFA, audit logs, least privilege, joiner-mover-leaver SCIM provisioning, RBAC/ABAC reviews, CAEP / SSF event streams

The pattern

Regulators set a behaviour requirement → standards bodies (OIDF, IETF, W3C, ISO) wire a protocol that satisfies it → vendors and OSS projects ship products that implement the protocol. Three-step flow, every time. Watch the regulators to know what's coming next.

15

How To Read This Series — Eleven Decks, One Map

The decks are ordered to be read top to bottom — but each is self-contained, so you can also drop in by topic. The two halves (Identity & Access = AuthN, Authorisation = AuthZ) interlock at the JWT / SVID / claims layer.

Identity & Access — "who"

  • 0. (you are here) Identity & Authorisation Primer
  • 1. Authentication Methods — passwords, MFA, passkeys, recovery
  • 2. OAuth — A Gentle Primer (Part 0)
  • 3. Introduction to OAuth (Part 1) — the protocol
  • 4. OAuth for MCP Servers (Part 2) — agents + provider zoo
  • 5. Introduction to OpenID Connect — IDs on top of OAuth
  • 6. Advanced OpenID Connect — FAPI 2.0, Federation, EUDI
  • 7. SAML 2.0 & SCIM — the enterprise stack

Authorisation — "what may"

  • 8. Authorization Models — RBAC / ABAC / ReBAC, Policy-as-Code
  • 9. Workload Identity & Service-Mesh AuthZ — east-west
  • 10. Edge & Gateway AuthZ — north-south

Reading order by goal

  • "I'm building a SaaS login": 1 → 2 → 3 → 5 → 7 → 8
  • "I'm hardening an MCP / agent": 2 → 3 → 4 → 10
  • "I'm an SRE wiring a mesh": 9 → 10 → 8
  • "I'm in B2B / enterprise": 7 → 5 → 6 → 8
  • "I'm preparing for EU AI Act / EUDI": 6 → 4 → 10 → 15

Companion decks (already in the index)

Cloud `*aaS` 05 — Cloud Security · Docker for LLMs, Agents & MCP · Introduction to Web Authentication · Introduction to Passport.js · Introduction to Express Middleware

16

Take-aways & References

Three sentences you can screenshot

  1. AuthN and AuthZ are different decisions, computed by different code, against different sources. Most real incidents come from confusing them.
  2. The whole field is sixty years of moving identity outward — from a file on one machine, to a network ticket, to a federated assertion, to a user-held wallet credential, to an AI agent's token.
  3. Buy AuthN, build AuthZ on a policy engine. Login is commoditised; what users may do is your business logic.

Three things to do next

  • Open Authentication Methods (deck 1) and look at the AAL ladder — it tells you what "secure enough" means in your domain.
  • Run a one-pager that lists, for each user-facing entry point you own: who validates the token? who decides the action? where is it logged?
  • Pick one authoriser in your stack and ask which threat from slide 9 it actually mitigates. If the answer is "I'm not sure", you've found a deck to read.

Canonical references

  • Saltzer & Schroeder, "The Protection of Information in Computer Systems" (1975)
  • NIST SP 800-63-4 (Digital Identity Guidelines)
  • NIST SP 800-207 (Zero Trust Architecture)
  • OWASP API Security Top 10 (2023)
  • OWASP ASVS v5.0 (Application Security Verification Standard)
  • Aaron Parecki, "OAuth 2.0 Simplified"
  • Justin Richer & Antonio Sanso, "OAuth 2 in Action"
  • Google "BeyondCorp" papers (2014-2017)
  • Google "Zanzibar" paper (USENIX 2019)
  • eIDAS 2.0 + EUDI Wallet ARF v1.4

Where the field is heading

User-held credentials replacing IdP databases. Agents as first-class principals with their own audit trail. Policy engines moving into the data layer. Phishing finally dead at scale via passkeys.