IntegrAuth Academy

Start here — never touched code? Perfect

If you've never written a line of code, never heard anyone say "server" or "JSON" and quietly nodded along in a meeting — this track was built for exactly you. We start from zero, explain every single word, and lean on everyday things you already understand: post offices, restaurants, hotel keys, wax seals. No jargon sneaks in unexplained. By the end you'll follow what happens between "type an address" and "you're logged in" — the ground every other track stands on.

Why begin here

The rest of the Academy talks about identity and security — proving who you are, keeping thieves out. But all of that rides on a handful of plain ideas about how computers talk to each other. Learn those first and the fancier tracks stop feeling like a foreign language; skip them and every lesson feels like walking in halfway through a film. So this track is the film's opening scenes.

The journey

We follow one simple question — "what really happens when you visit a website and sign in?" — and unpack it one small piece at a time. First how the web moves a page to your screen, then the little language browsers and servers speak, then why the server keeps forgetting you (and how it remembers), then how apps trade data, how computers pack that data up, how locks and seals keep it honest, the tidy "badge" that carries who-you-are, and finally passwords done right. Then a cheat sheet and a friendly pop quiz.

1. How the web works — your browser, a far-away server, and the trip a page makes to your screen.
2. HTTP basics — the simple request-and-reply language every website speaks.
3. State & sessions — why the server forgets you between clicks, and the wristband that helps it remember.
4. APIs & JSON — how apps ask each other for data, and the tidy format they send back.
5. Encoding vs encryption — packing data neatly is not the same as locking it away.
6. Keys, locks & the padlock — what that little padlock really promises (and what it doesn't).
7. What a token looks like — the signed "badge" an app hands you after you sign in.
8. Passwords done right — why good sites never actually store your password.
9. Cheat sheet & pop quiz — the whole track boiled down, then five gentle scenarios.

How to use it

Read one lesson at a time — they're short. Your progress saves right here in your browser — no account needed, and signing in syncs it across your devices. Most lessons end with a little hands-on lab you can poke at safely (nothing you do leaves your screen), and the track finishes with a cheat sheet and quiz. Take breaks. Re-read anything twice. There's no clock.

Every journey starts with a single step. Begin with how the web works and follow it from there — and when you finish this track, Foundations picks up right where you leave off.

What actually happens when you visit a website

You type an address, hit enter, and a page appears. It feels instant and magical — but underneath it's just two computers passing notes. Let's slow that moment right down and watch every step, because once you can picture it, the whole rest of the Academy clicks into place.

Two computers, one conversation

Your browser is a program on your device — that's all a program is: instructions a computer follows. The browser's whole job is to fetch pages and draw them. Because it does the asking, we call it the client. A server is just another computer, usually sitting in a data centre far away, whose job is to answer. It's not mysterious — "server" literally means the thing that serves, like a waiter. Every website you visit is a conversation between a client that asks and a server that answers.

The address bar has parts

The address you type — the URL (web address) — isn't one blob. It's several pieces, each telling the browser something specific. Take a flight-booking site: https://travel.example/flights?from=BLR&to=DXB.

But wait — where is travel.example?

Computers don't actually find each other by name; they use numbers called IP addresses, like 203.0.113.7. Names are for humans. So before your browser can knock on the server's door, it has to look up the number for the name. That lookup is done by the DNS — think of it as the internet's phone book. You say "travel.example", it hands back "203.0.113.7", and now your browser knows where to go. Only then does it send its request and get the page back.

HTTP — the language browsers and servers speak

In lesson 1 a browser asked and a server answered. But what does "asking" actually sound like? Browsers and servers speak one simple language called HTTP, and it's just a tidy back-and-forth: you send a request, you get a response. Learn its shape once and you'll recognise it everywhere for the rest of your life.

A request has four parts

Every request is: a method (what you want to do), a path (which thing), some headers (extra notes), and sometimes a body (data you're sending along). A response comes back as: a status code (how it went, as a number), its own headers, and usually a body (the actual page or data). That's the entire game — everything else is detail.

The four everyday verbs

The method is a verb: it says whether you want to read, create, replace, or remove something. Picture ordering at a restaurant.

The answer is a number

The server replies with a three-digit status code, and the first digit tells you the mood at a glance. You don't memorise hundreds of them — you learn the families.

Three from the 4xx family are worth knowing by name right now, because they show up constantly in the identity world: 401 Unauthorized ("I don't know who you are"), 403 Forbidden ("I know who you are, but you're not allowed"), and 404 Not Found ("there's no such thing here").

Cookies & sessions — how a forgetful web remembers you

Here's a strange fact about the web: it forgets you the instant it answers you. Every single request to a website starts from a blank slate — the server has no memory of the last thing you did. So how does a site keep you logged in across page after page without asking for your password each time? With a tiny note called a cookie.

The web has no memory

In the previous lesson (how the web talks) we saw that a browser asks and a server answers, one request at a time. What that lesson didn't say out loud: those requests are stateless — the server treats each one as if it had never met you before. Ask for page 1, then page 2, and as far as the server knows, two total strangers just walked in. That's fine for reading, but the moment you log in, the site needs a way to say "oh, it's you again."

The little name-tag: a cookie

When you log in, the server hands your browser a cookie — a small note, usually just a random code like session=abc123. Your browser tucks it away and, without being asked, automatically re-attaches that same note to every later request to that site. Meanwhile the server keeps a matching entry in its own guest-list — the session — that says "abc123 is Maya, logged in five minutes ago." Cookie in hand, the server flips to that entry and knows exactly who you are.

Cookie vs session — who holds what

What is an API? (and what's this JSON thing?)

Every app on your phone is quietly chatting with the internet all day long — checking the weather, loading your messages, showing flight prices. It does that through APIs. An API isn't a scary thing; it's just a menu of things one program is willing to do for another program. Let's order from it.

An API is a menu

An API (Application Programming Interface) is a published list of requests one program lets another program make — and it uses the exact same ask-and-answer HTTP from the how the web talks lesson. There's just one twist: instead of replying with a whole web page for your eyes, an API replies with data, ready for another program to use.

JSON: the note the waiter carries

When an API answers with data, it writes that data in a tidy format almost everyone agrees on: JSON. It looks like this: {"name": "Maya", "seat": "12A"}. Read it out loud — curly braces { } wrap the whole note, and inside are "key": value pairs separated by commas. A key names a thing ("seat"); the value is the answer ("12A"). When you have a list of things, they go in square brackets [ ]. That's basically all of it. Humans can read JSON at a glance, and programs adore it because it's so predictable.

A tiny flight API

Say an airline offers an API. Its menu — the list of endpoints — might look like this:

Remember GET means "read me something" and POST means "create something," just like the last lesson. The app on your phone fires off dozens of these little requests, gets back JSON, and paints it onto your screen as buttons and lists.

Encoding, encryption, hashing — the three everyone mixes up

These three words sound alike, get thrown around interchangeably, and mean completely different things. Mixing them up isn't just sloppy — it's how real security disasters happen ("don't worry, it's encoded!"). Let's untangle them once and for all, in plain English, with zero maths.

Encoding — repackaging, not hiding

Encoding is just repackaging data into a different shape so it travels safely — nothing more. The most famous one is Base64, which turns any data into a plain string of safe letters and numbers. Anyone can undo it instantly; there's no key, no secret, no lock. It offers zero secrecy.

Encryption — a real lock with a key

Encryption scrambles data with a key so that only someone holding the matching key can unscramble it. It is reversible — but only with the key. Take the key away and the scrambled output is useless gibberish. This is the real thing that protects your data as it crosses the internet (the padlock in your browser's address bar is encryption at work).

Hashing — a one-way fingerprint

Hashing runs your data through a one-way blender and spits out a fixed-size fingerprint. Two rules make it magic: the same input always gives the same fingerprint, and changing even one character produces a totally different one. The catch — and the whole point — is that you can't run it backwards. There's no key that turns the fingerprint back into the original. That's why hashing is how passwords should be stored (more on that in how passwords are really stored).

Keys, signatures & the padlock — a gentle intro to crypto

Last lesson we said encryption needs a key — but where do keys come from, and how could two strangers ever agree on one while a thief is listening? Answering that is where security gets clever. Meet the humble key pair, the wax seal, and that little padlock in your address bar.

One key, or two?

The oldest idea is symmetric encryption: one shared key that both locks and unlocks. The same secret scrambles Maya's message and unscrambles it for Sam. Fast and simple — with one catch that sinks it: before you can talk secretly, you first have to get the key to the other person. Mail the key and a thief can copy it in transit. Chicken, meet egg.

The two-key trick

The fix is asymmetric encryption: instead of one key you get a pair. A public key you can hand out to the whole world, and a private key that never leaves home. What one locks, only the other unlocks — and you can never work out the private key from the public one.

Now run it backwards

Here is the move that powers almost everything: use the keys the other way. Priya signs with her private key, and anyone can verify that signature with her public key. It is a wax seal only she can press, yet everyone can recognise — proof that she wrote it and that not one letter has changed since. That reverse trick is exactly what seals a JWT (next lesson), and what stands behind the padlock.

The little padlock

When you see TLS (the https padlock), two things just happened. The site proved who it is with a certificate — a public key vouched for by someone your browser already trusts — and then your browser and the server used that to agree on a fresh, temporary shared key. From there they switch to fast symmetric encryption for the actual traffic. Asymmetric to introduce themselves; symmetric to do the heavy lifting.

What is a JWT? Your first token, read byte by byte

You log in once, and somehow every page after that still knows it's you — without asking for your password again. The trick is a token: a little pass the server hands your app to carry instead of your password. The most common kind is the JWT, and by the end of this lesson you'll read one by eye.

Why a token at all?

Earlier we saw the web forgets you between requests, so something has to say "still me" each time. A cookie is one way to carry that proof; a JWT is what's often inside the modern version. After you sign in, the server mints this token and gives it to your browser or app, which then shows it on every request — like flashing a wristband instead of re-buying your ticket at every door.

Three parts, two dots

A JWT (say "jot") is just three chunks of Base64 glued together with dots: header.payload.signature. The header says what kind of token it is and which algorithm sealed it. The payload holds the claims — the actual facts. The signature is the wax seal from the last lesson, proving the whole thing is genuine and unchanged.

Reading the claims

The payload is where beginners get their footing. A handful of short, standard claims answer very human questions:

How websites store your password (spoiler: they don't)

Here's a test you can run on any website. Click "forgot password". If it emails you your old password, close the tab and never come back — because it just told you it keeps your password in a form it can read. A well-built site literally cannot do that. Here's why.

Store the fingerprint, not the face

A good site never saves your actual password. Instead it saves a hash of it — a one-way fingerprint. When you log in, it fingerprints what you just typed and compares it to the stored one. Same fingerprint, same password, door opens. The real password was never written down, so a thief who steals the database gets a pile of fingerprints, not passwords.

A pinch of salt

One problem: two people who both pick hunter2 would get the same fingerprint, and attackers keep giant precomputed tables of "fingerprint → common password". The fix is a salt: a random pinch mixed into each person's password before hashing. Now the two hunter2 users store completely different fingerprints, and those precomputed tables become useless.

Slow on purpose

A plain fingerprint is fast to compute — and so is a billion of them, which is exactly what a cracker wants. So proper password hashing uses a deliberately slow recipe (names you'll meet later: bcrypt, scrypt, Argon2). Slow enough that one login is unnoticeable, but guessing through millions would take years. Salt kills the shortcut; slowness taxes the brute force.

The big picture — one visit, told end to end

Eight lessons ago, a page appearing on a screen was pure magic. Now you can name every step behind it. So let's replay one ordinary moment — Maya booking a flight at travel.example — from the address bar to the token she carries, and watch how everything you learned was quietly there the whole time.

The story you just lived

Maya types travel.example and hits enter. Before any page can arrive, her browser has to find the place at all — the name-to-number lookup we slowed right down in what happens when you visit a website. With an address in hand, two computers start passing notes in the tidy language of HTTP: a request goes out, and a numbered answer comes back — 200 OK, here are the flights.

That first page was public, so it came back with no questions asked. But the moment Maya signs in and clicks "my bookings," the forgetful web should shrug and ask "and you are…?" all over again. It doesn't — because of the little name-tag from cookies & sessions: she typed her password once, the server handed back a cookie, and now that cookie rides along on every request so the server keeps recognising her page after page.

Under that smooth-scrolling page, Maya's app is trading data with the server through the menu of requests we met in what is an API — small JSON notes, not whole web pages. And the wording on those notes is protected by the three words you can finally tell apart from encoding, encryption & hashing: Base64 that repackages but hides nothing, encryption that truly locks, and hashing that fingerprints one way only.

That little padlock in her address bar? You cracked it open in keys, signatures & the padlock: a key pair — a public slot anyone may post into, a private key only Maya's side holds — plus the signatures that make any tampering obvious. The pass she carries silently from page to page is the JWT you read byte by byte: plain enough to read, impossible to forge. And the password she typed that one time? The site never actually kept it — it stored only a salted, deliberately-slow fingerprint, exactly as we saw in how websites store your password. One visit. Every idea, all at once.

The threads that tie it together

Where these ideas go next

You speak web now — so meet identity itself. The Foundations track takes these pieces and asks the human questions: who are you, and what may you do. When you're ready for the grown-up version of reading that boarding-pass token, validating a JWT shows the real checks an API runs before it trusts one. And to see what finally retires the password Maya keeps forgetting, start with passkeys.

Feeling solid? Prove it — the cheat sheet & pop quiz is one page away.

Cheat sheet & pop quiz

Eight lessons taking you from "what's a server?" to reading a token by eye — here's the whole track boiled down to a cheat sheet, a quick-reference lookup, and five scenarios to prove it stuck.

Eight ideas, one per lesson

Quick reference

Pop quiz — five questions

Start here — the lay of the land

Every big idea in identity is easier once you've met the people it happens to. This track hands you six fictional characters — Maya, Sam, Priya, Bot A, Kai and Zara — and teaches the whole field through their days, starting from absolute zero. By the end, "OAuth" won't sound like a sneeze.

What you're walking into

Identity is the quiet layer under every app: the machinery that decides who is knocking and what they're allowed to do. Foundations is the ground floor — no prerequisites, no acronym left unexplained. If you can picture a receptionist checking a badge, you already have the intuition; we'll just give it the right names.

The journey

The lessons climb in four moves. Lessons 1–4 hand you the vocabulary — who the cast are, what an identity even is, how you prove it, and the token that carries the answer. Lessons 5–7 pull back to the systems view: one person wearing many hats, zero trust, and what happens the day an account is compromised. Lessons 8–9 cross into the new frontier of machine and AI-agent identity. And 10–12 are the rulebook and the recap.

1. Meet the cast — the six characters every later idea is taught through.
2. What is identity — the digital stand-in for a person or thing.
3. Proving who you are — the three factors, plus real-world proofing.
4. Tokens & acronyms — OAuth, OIDC, JWT and SAML, demystified.
5. Joiner, Mover, Leaver — keeping access in step with reality.
6. Personas & the fabric — one human, many roles, one blind spot.
7. Zero trust — verify every access on its own merits.
8. When things go wrong — detect fast, revoke everywhere.
9. Non-human identities — the accounts nobody watches.
10. AI agents & MCP — software that decides and acts.
11. The rules of the game — the duties every regulator shares.
12. A–Z glossary — every acronym you met, one line each.
13. Cheat sheet & pop quiz — the distillation, then prove it stuck.

How to use the Academy

Take one lesson at a time. Your place and progress save right in your browser — no account needed — so you can stop mid-track and pick up later; sign in and they follow you to your other devices. Most lessons end with a hands-on lab you can poke at in the page, and every track closes with a cheat sheet & pop quiz that unlocks only once you've revealed all five answers.

Ready? Meet the cast and we'll begin at the very beginning.

Meet the cast

This whole track follows six characters through their days. Every idea is taught through them, so by the end you'll recognise an entire identity programme just from their stories. All of them are fictional.

What is identity, really?

Before any technology: an identity is a digital stand-in for someone (or something) the business needs to recognise. Maya the human is not inside the computer — her identity is.

Three words people mix up

The two big questions

Every security decision ever made boils down to two questions, and it pays to keep them apart:

Who answers "who are you?" — the IdP

Companies centralise the "who are you?" question in an identity provider (IdP) — one specialised system that checks credentials and then vouches for you to every other application. That is also what makes single sign-on (SSO) possible: sign in once, and the IdP vouches for you everywhere else.

Most companies run two IdPs, because staff and customers are governed very differently. A workforce IdP handles employees like Priya — this category is EIAM (enterprise identity & access management), sometimes "workforce IAM" or B2E. A separate customer IdP handles people like Maya — CIAM (customer identity & access management), or B2C. Partner organizations like Sam's employer sit in a third bucket, B2B. Same discipline, three audiences.

A few more words you'll meet immediately

Proving who you are — factors, proofing & assurance

"Password, please" is 1995. Modern proof comes in layers: what you know, what you have, what you are — plus checks that the real-world person behind the account is genuine.

The three factors, and MFA

Multi-factor authentication (MFA) simply means requiring two or more different factors. A password plus a phone code is MFA — but note that SMS OTP is a weak link, defeated by SIM swaps and interception, and acceptable only as a fallback.

Passkeys — the password's retirement plan

A passkey (built on the WebAuthn (W3C) and FIDO2 (FIDO Alliance) standards) is a cryptographic key pair stored on your device and unlocked with your fingerprint or face. There is no password to phish, guess or reuse — the secret never leaves the device. That is why passkeys are called phishing-resistant, and why modern programmes make them the preferred factor.

Step-up: stronger proof at the risky moment

Step-up authentication means the system asks for more proof only when the action is risky. Reading a balance: stay logged in. Sending $2,500: confirm on your phone with a fingerprint first. You'll meet the machinery for this (acr, CIBA) in the tokens lesson.

Identity proofing — is the human real?

Authentication checks you own the account. Identity proofing checks the account belongs to a real, verified human: scanning an ID document, matching a selfie to it with liveness, checking official registries. Done electronically it's called eKYC.

Assurance — trust as a number

Once you accept that proof comes in strengths, you can score it. An assurance level is that score, tracked on separate dials. NIST SP 800-63 defines levels 1–3 for the first two; many platforms add a session dial and finer-grained scales:

Tokens & the standards alphabet soup

Almost every acronym that scares beginners — OAuth, OIDC, JWT, SAML, SCIM, acr, CIBA, RAR — is just machinery around one simple object: the token.

What a token is

Three tokens you'll hear about, all issued by the IdP:

Inside a token: JWT, claims, scopes

Most tokens are JWTs (JSON Web Tokens) — three parts, cryptographically signed so nobody can forge or edit one:

Claims are the facts inside the token (who, when, what level). Scopes are the permissions it grants ("may read invoices, may pay"). Two claims matter for step-up: acr (how strong was authentication — the assurance level from the proof lesson) and amr (which method — passkey? OTP?). An API can say "this action needs acr ≥ level-4" — that's step-up, enforced.

The protocols, one line each

Putting it together: Maya's big transfer

The lifecycle — Joiner, Mover, Leaver

Access is easy to give and hard to take back. JML (joiner–mover–leaver) is the discipline of keeping access exactly in step with someone's real-world status — automatically.

The vocabulary of giving (and taking away)

Personas & the identity fabric

Here is the heart of modern identity security. One human can be customer, employee and partner at the same time — and in most organizations the systems can't see that it's the same person. Fraud lives in that blind spot.

The three-way collision

So what is an identity fabric?

An identity fabric doesn't replace your IdPs — it connects them. Like threads in a cloth, it weaves the workforce IdP, the customer IdP, the PAM vault, HR and even stubborn old application databases into one layer that can answer: who is this identity, everywhere, right now — and what should we do about it? One view, one policy voice, one audit trail, one kill switch.

The unified record of a person across everything is often called an identity 360 view, and the merged record at its center is the golden customer record — a single reconciled profile that every system can agree on.

Three ways to weave the fabric

Access models: RBAC → ABAC → ReBAC

Zero trust & context — never trust, always verify

Old security was a castle: get past the moat (the office network, the VPN, an approved IP address) and you're trusted. Zero trust demolishes the castle — every single access is verified on its own merits, wherever it comes from.

Context: the signals behind every decision

Zero-trust decisions feed on context: who (persona, assurance level), what (device health — is it patched, managed, jailbroken?), where (location, network), when (shift hours?), and how risky (recent fraud signals?). Network-level enforcement products are called ZTNA (zero-trust network access), and a policy engine ties the signals together. The same evaluation can end three ways: allow, step-up (prove more), or deny.

Who decides? PEP, PDP, PIP

The judge's rulebook increasingly lives in a dedicated policy engine. Three names you'll meet: Open Policy Agent (OPA) — general-purpose rules written in a language called Rego; Cedar — a policy language for permissions; and OpenFGA — the relationship-graph flavour that powers ReBAC from the personas lesson. Different syntax, same idea: policies live in version control, get code-reviewed and unit-tested like software, and every decision they make is logged.

One more idea completes the picture: continuous access evaluation. A classic session is judged once at login; continuous evaluation means that if the context changes mid-session — risk spikes, a device is reported stolen, a persona is delinked — the session is re-judged immediately, not at the next login. The signalling that makes this possible, CAEP / Shared Signals (OpenID), stars in the CAEP lesson.

When things go wrong — kill switch, ITDR & ISPM

This is Zara's chapter: detection, hygiene, and the big red button. Sooner or later an account is compromised — the winners are the teams that notice fast and can pull access everywhere in under a minute.

The fraud bestiary

Fraud isn't one thing. A handful of patterns show up again and again, and naming them is half the battle.

The kill switch — anatomy of a rescue

The tokens lesson planted the problem: a stolen session and already-issued tokens keep working until they expire. The kill switch — one trigger that makes an identity's access die everywhere at once — is the answer, and it needs three pieces of machinery.

The defence trio: ITDR, ISPM and the SOC stack

Non-human identities — Bot A's chapter

For every human identity, companies now run dozens of non-human ones. They never resign and never get phished — and that's precisely the problem: nobody watches them.

Bot A gets its life in order

A non-human identity (NHI) — any login that belongs to software rather than a person — deserves the same discipline you'd give an employee. Here is Bot A's clean-up checklist.

How a workload proves itself — SPIFFE & SPIRE

Workload identity has its own open standards. SPIFFE (Secure Production Identity Framework For Everyone) gives every workload a universal name — spiffe://acme/refunds/bot-a — and defines a short-lived cryptographic ID document called an SVID. SPIRE is the software that issues them: it attests a running workload ("is this really the refunds service, on the blessed cluster, from the approved image?") and only then hands over an SVID valid for minutes. That is the ideal taken to its conclusion: no stored secret anywhere — identity comes from what the workload provably is, not from what it holds.

AI agents & MCP — Kai's chapter

An AI agent is software that uses AI to decide and act: it reads a request, plans steps, and calls tools — often on behalf of a person. Bot A follows a script; Kai improvises. That's the power, and the danger.

Five links in every chain

OBO — acting for, never as

On-behalf-of (OBO) is the delegation pattern modern architectures insist on: Kai has his own identity and carries Priya's authority alongside it — both visible in every token and log line. The forbidden alternative is impersonation: logging in as Priya, indistinguishable from her. Mechanically, OBO runs on token exchange (RFC 8693, from the tokens lesson): Kai trades "Priya asked me" for a narrower token scoped to the task.

Delegation is one of several agent identity patterns you'll see catalogued in registries: fully autonomous (the agent acts on its own standing authority, no human behind the request), on-behalf-of (Kai + Priya, above), and ephemeral task-scoped — an identity minted for one task and destroyed with it, so afterwards there's nothing left to steal. Matching each agent to the right pattern is the first design decision in every agent onboarding.

MCP — the doorway with a guard

MCP (Model Context Protocol) is an open standard for connecting AI agents to tools and data. Think of each MCP server as a doorway to one system. Security-wise this is wonderful news: if agents can only reach systems through doorways, then the doorways are where you check identity, policy, and log everything.

Trusting the software itself — supply-chain integrity

Registered agents and guarded doorways rest on one more assumption: that the software is what it claims to be. Supply-chain security earns that assumption with three checks.

Two companions round this out. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the classic threat-model checklist — walk every link of the chain asking "how could this be attacked?" before an attacker does. And a model card does for the AI model what the agent card does for the agent: a fact sheet of what it was trained for, its known limits, and how it may be used.

The agent threat zoo — and the guardrails

Guardrails are the countermeasures: input/output screening for injections, PII masking (personal data redacted from tool responses before the model sees it), anomaly detection on tool-call chains, and red-team testing. Add HITL (human-in-the-loop) for high-risk actions — a decoupled approval with rich authorization (RFC 9396), Kai as the requester — and an agent card (the registry's one-page passport per agent: owner, purpose, allowed tools, risk tier, review date).

The rules of the game — regulations & certifications

Identity work is regulated work. The names differ by country — the duties rhyme: know who you're serving, protect their data, and be able to prove both.

A short global tour

A–Z glossary — every term in one place

One line each; the lessons give the full picture. Every acronym you met, alphabetised.

The big picture — the whole field, one story

You walked in with "OAuth" sounding like a sneeze. You leave able to read an identity-architecture diagram and name every box on it. This track handed you a cast of six and taught the entire field through their days — so before the quiz, let's watch those days line up into one continuous story, from the very first "who are you?" to the rulebook that governs it all.

The story you just lived

It began with people, not technology. We were introduced to six characters whose ordinary days carry the whole discipline in meet the cast — Maya the customer, Sam the partner, Priya the employee, Bot A the RPA bot, Kai the AI agent, Zara the security operator. Then the first real question: what is identity, really?, where we split the two things beginners forever blur — who you are (authentication) from what you may do (authorization). Proving the first is its own craft, layered in proving who you are: what you know, have and are, plus passkeys and step-up and the awkward matter of checking the human is even real.

Once someone is proven, they're handed a small object that the rest of the system trusts — and nearly every acronym that scares newcomers turns out to be machinery around it, as tokens & the standards alphabet soup revealed. But access granted must not outlive the reason for it, so the lifecycle — joiner, mover, leaver gave us Sam resigning by text and the discipline of pulling his access the same day. And because one human can be customer, employee and partner at once, personas & the identity fabric lit up the blind spot where fraud lives — linked for risk, separated for access.

Then the security posture turned modern. Zero trust & context demolished the old castle — every access verified on its own merits, wherever it comes from — and when an account is compromised anyway, Zara's chapter, when things go wrong, taught detection, hygiene and the big red kill switch that pulls access everywhere in under a minute.

Finally the cast grew past humans. For every person, a company runs dozens of non-human identities — service accounts, workloads, Bot A itself — that never resign and never get phished, which is exactly why nobody watches them. The most autonomous of them improvise: the AI agents & MCP that act for Priya, never as her, carrying her authority through every hop. And all of it is regulated work, so we closed on the rules of the game — the duties that rhyme across every border. Every acronym you met along the way is waiting on the reference shelf: the A–Z glossary.

The threads that tie it together

Where these ideas go next

Pick a box and go deep. Modern Authentication opens up the "prove who you are" corner — passkeys, MFA and the death of the password. Authorization models takes the "what may you do" half and turns it into policy you can write and test. And to follow the most autonomous cast members all the way down, the AI & agents track builds directly on non-human identity and MCP.

Think it all stuck? Put it to the test — the cheat sheet & pop quiz is the very next page.

Cheat sheet & pop quiz

You've met the whole cast and the whole vocabulary. Here's the twelve-idea distillation, a map to where to go deeper, and five questions to prove it stuck.

Twelve ideas that unlock everything

Keep going — from foundations to the deep dives

Each foundations lesson has a working counterpart deeper in the Academy. Read the idea here, then go build it there.

Pop quiz — five questions

Start here — beyond the password

Maya has forgotten her password again. She reuses one across a dozen sites, a breach dump already lists it, and a lookalike page is waiting to catch her next typo. This track is the story of retiring that password for good — and making the login that replaces it both safer and smoother.

The problem with "just log in"

A password is a shared secret, and shared secrets get phished, reused, and leaked. Modern authentication attacks the whole idea from two sides: remove the secret entirely, then make whatever proof remains adapt to the risk of the moment — heavier when something looks off, invisible when it doesn't.

The journey

Lessons 1–2 kill the password with passkeys and well-run MFA. Lessons 3–6 make friction smart — scoring each sign-in for risk, asking for fresh proof only before risky actions, and turning bots and breached passwords away at the door. Lessons 7–9 tackle signing in once and staying signed in everywhere: enterprise SSO, what actually happens after login, and carrying a session from a native app into the web. Lesson 10 proves it all stuck.

1. Passkeys & WebAuthn — replace the shared secret with a key that can't be phished.
2. MFA & factors — enroll a second factor without locking yourself out.
3. Adaptive MFA — challenge the sketchy sign-ins, wave the rest through.
4. Step-up & assurance — demand fresh proof right before a risky action.
5. Bot detection — make credential stuffing expensive, even in an embedded login.
6. Breached passwords — block known-leaked passwords without ever seeing them.
7. Enterprise SSO — route each user to their own corporate login, automatically.
8. Sessions & sign-out — what happens after login: cookies, flags, and clean logout.
9. Native-to-web SSO — carry a signed-in session across the app-to-web gap.
10. Magic links & email OTP — passwordless that feels like magic, and the caveats hiding in the inbox.
11. Identity verification — proving there's a real human behind the account, not just a valid login.
12. Cheat sheet & pop quiz — the whole track distilled, then five scenarios.

How to use it

One lesson at a time; your progress saves in your browser — no account needed, and signing in syncs it across your devices. Most lessons end with a hands-on lab, and the closing cheat sheet & pop quiz unlocks once you've revealed all five answers. New here? The Foundations lesson on proving who you are is a gentle warm-up.

Passwords have had their run. Start with passkeys & WebAuthn and watch the shared secret disappear.

Passkeys & WebAuthn

A passkey throws away the password and replaces it with a pair of cryptographic keys — one that never leaves your device, and one the website keeps. There is no shared secret left to phish, reuse, or leak in a breach.

What a passkey actually is

When you "create a passkey", your phone or laptop generates a key pair — two mathematically linked keys. The private key stays sealed on the device behind your fingerprint, face, or PIN (or is end-to-end encrypted if it syncs); the matching public key is handed to the website. To sign in, the device signs a one-time random challenge with the private key, and the server checks that signature against the public key it stored. The secret half never crosses the wire. This is WebAuthn (W3C) — the open web standard, built with the FIDO Alliance, that every modern browser and OS implements.

Why they can't be phished

Each passkey is bound to a relying-party ID — the site's own domain. The browser will only ever offer a passkey to the exact origin it was created for, and the signature covers that origin. A look-alike phishing page physically cannot trigger the passkey you made for the real site — there is nothing to type, paste, or be tricked into approving on the wrong domain. That is the gap passwords and SMS codes can't close: both can be relayed to a fake site in real time. A passkey login surfaces as amr: phr ("phishing-resistant"), so APIs can require it for sensitive actions — see step-up & assurance.

Synced vs device-bound, and three ways to deploy

Synced passkeys back up across your devices through an end-to-end-encrypted provider store — lose one device, you still have the passkey on the others (NIST SP 800-63-4 recognises synced passkeys for AAL2). Device-bound passkeys (a hardware security key) never leave the one authenticator: stronger isolation and attestation, but no cloud backup. The same ceremony ships in three shapes, differing only in who plays relying party.

MFA enrollment & factors

Turning on multi-factor auth is the easy part. Doing it well is about which factor you enroll, how you enroll it safely, and — above all — how recovery survives a lost device.

The factor-strength ladder

Multi-factor authentication (MFA) means proving your identity with more than one kind of evidence. But not all factors resist the same attacks, so they form a ladder.

How in-app enrollment works

Enrolling an authenticator app without leaving your app uses a careful back-channel handshake — no hosted page. Your session's refresh token is exchanged for a short-lived MFA token that stays in the backend (never the browser) and authorizes the enrollment. The backend then calls the enroll endpoint, gets a secret and QR code, shows it to you, and confirms the factor once you type the first code.

Managing factors — and the reset gate

Once enrolled, factors can be renamed or removed. Removing one — and the nuclear "reset all my MFA" for a lost device — is gated behind proof of possession: a one-time code sent to a server-chosen verified channel (email or SMS). So a stolen session alone can't strip your protection. If your recent sign-in is stale, the system first re-proves your primary credential with a fresh login — never the second factor you may have lost.

Adaptive risk-based MFA

Challenging every login with a second factor annoys everyone and protects no one extra. Adaptive MFA scores each sign-in for risk and only challenges the sketchy ones.

Risk scoring, then a decision

Adaptive MFA is a policy that scores every login attempt for how risky it looks and steps up the risky ones. The engine reads signals — a new device or browser, an impossible-travel location jump, an IP with a bad reputation, an unusual time — and produces a confidence score. Low confidence (this doesn't look like Maya) triggers a challenge; high confidence lets a normal login glide through.

A browser login never sees this — an API login must run it itself

Through the hosted login page, adaptivity is invisible: the page shows the MFA challenge when risk is high and completes the login for you. But an app that logs in over a back-channel API grant gets no page. Instead the token call returns 403 mfa_required with a short-lived mfa_token, and the app must run the challenge itself.

Step-up & assurance

Being logged in is not the same as having just proven it's really you. Step-up asks for fresh, stronger proof right before a risky action — and the API is the thing that must check it came back.

Authenticate on the context, not just the identity

Every token carries an authentication context — evidence of how and when the user proved themselves. Three claims matter: amr (the methods used, e.g. mfa or phr), acr (the assurance class you asked for), and auth_time (when they last authenticated interactively). You bind each sensitive operation to a required rung of assurance.

The 401 step-up pattern

When the token is insufficient, the API doesn't just say "no" — it speaks a typed step_up_required that names the acr_values (and, for money movement, max_age) the client must re-authorize with. The app steps up, then retries the exact same call. Step-up (RFC 9470) standardises this OAuth challenge. Crucially, step-up sends acr_values — which challenges only the second factor on the existing session — not prompt=login, which forces a fresh primary credential (that lever is for lost-factor recovery).

Bot detection & the CAPTCHA handoff

Credential stuffing — replaying millions of leaked passwords against your login — is cheap to run and expensive to suffer. Bot detection makes it costly. But there's a catch: an embedded login literally can't draw a CAPTCHA.

Making automation expensive

Bot detection watches login and signup traffic for the fingerprints of automation — bursts of attempts, headless browsers, bad-reputation IPs — and, when a request looks robotic, demands a challenge a human can pass but a script can't (a CAPTCHA). Pair it with breached-password detection and brute-force throttling and you've drained most of the fuel from credential stuffing.

Where a CAPTCHA can actually be solved

Here's the subtlety. A challenge has to be rendered somewhere. An app logging in over a back-channel password grant has no screen the identity provider controls — so there is no back-channel way to solve a CAPTCHA. Instead the token call returns requires_verification, and the app must hand the user off to the hosted login page, where the CAPTCHA is drawn, solved, and verified.

Breached-password detection

Billions of passwords sit in public breach dumps. If a user picks one of them, you already know their account is a sitting duck — so check, and block, before the damage is done. The clever part: you can check without ever seeing the password.

The k-anonymity trick

How do you ask "is this password in a breach corpus?" without sending the password anywhere? With k-anonymity — a range query that reveals almost nothing. The backend hashes the password with SHA-1, sends only the first 5 hex characters of that hash to the breach API, and gets back every hash suffix that shares those 5 characters (hundreds of them). It then matches the full suffix locally. The full password, and even its full hash, never leave the server.

Block, don't warn — and standard vs continuous

A warning the user can click past is not a control. On a confirmed match, block the authentication and route to a guided reset; notify the user and admins so the same credential reused elsewhere gets rotated too. Coverage comes in two grades: standard detection matches a dataset that refreshes periodically, leaving a window; continuous feeds catch freshly-leaked credentials in hours, not on the next cycle.

Enterprise SSO & home-realm discovery

Your enterprise customers already have an identity provider. They don't want a new password — they want their own corporate login. The trick is routing each user to the right one without ever asking them to choose.

Let customers bring their own IdP

Enterprise SSO (single sign-on) lets a customer's workforce sign in to your app with their existing corporate identity provider over a federation protocol — SAML or OIDC. You don't store their passwords; you trust an assertion from their IdP. But if you host a thousand customers, how does a login know which IdP a given person belongs to?

Home-realm discovery: the email domain is the map

Home-realm discovery (HRD) answers exactly that: it maps an email domain to the enterprise connection that should authenticate it. The hosted login page takes the identifier first, reads the domain after the @, matches it to a configured connection, and redirects the browser straight to that IdP. Priya types priya@bigcorp.com, and without picking anything from a menu she lands on Bigcorp's own login. On return, a user is created just-in-time — provisioned on first login from the assertion.

Sessions, cookies & sign-out

Every course teaches you how to sign in. Almost nobody teaches you what exists the second after: a session. Maya's login was a single moment; her session is the hour that follows. And a sign-out is only real if every session that login spawned actually dies — which, it turns out, is where most apps quietly fail.

Three sessions, three lifetimes

When Priya signs in through enterprise SSO, she doesn't create one session — she creates three things on three different clocks, and confusing them is the root of most logout bugs.

The session cookie and its armor

An app session is only as safe as the cookie that carries it. Four flags are the difference between a cookie and a stealable bearer credential:

Sign-out done right

Here's the trap: clearing the local cookie is not logout. Delete App A's session cookie and the IdP session is still very much alive — so the moment Priya revisits App A, SSO silently signs her right back in, and any unexpired tokens keep working. Real sign-out has to reach further:

Single logout across the estate — Priya leaves

Now the offboarding question: Priya resigns. How many sessions must die? Not one — the IdP session, every app session, and the refresh tokens behind them, everywhere she was signed in. That's single logout, and back-channel logout is what fans the kill-signal out across an SSO estate reliably. For the modern, cross-vendor version that reaches even systems outside the logout loop, a CAEP session-revoked event over Shared Signals broadcasts "this subject is gone" so receivers drop her in seconds. It's the natural endpoint of the Joiner–Mover–Leaver lifecycle: access granted at the door must be revocable at the door, in one motion.

Native-to-web SSO

Your native app has the user signed in. It launches a web page — and suddenly they're a stranger again, staring at a login box. Native-to-web SSO carries the sign-in across that gap, with no second login and no shared secret.

The gap between native and web

A native app signs in over an API grant and holds a refresh token, but it has no browser session to hand to a web app it opens. So the launched web app has nothing to trust. The native-to-web SSO pattern bridges that with a session-transfer token — a single-use, ~60-second ticket that lets the web app sign the user in silently, yet get its own independent session.

Two ways to redeem, and what keeps it safe

Redemption runs either front-channel (the browser visibly visits the IdP and is redirected back — always works, may briefly show a screen) or back-channel (the backend calls /authorize itself and seals the session server-side — silent, but only when no interactive page is needed). Either way, the user now has two independent sessions for one identity: different clients, cookies, and token sets, each refreshing and revoking on its own.

Magic links & email OTP — passwordless, with caveats

Maya clicks "email me a login link," checks her inbox, taps the link — and she's in. No password typed, none to forget. It feels like magic. But magic has fine print, and the fine print is her email account.

What a magic link actually is

A magic link is a sign-in link the app emails you: click it and you're logged in, no password required. Under the hood it's a single-use token — a long, unguessable string that is valid once and only for a short window (say ten minutes). The app sends it to a channel you already control — your inbox — and receiving it back proves you control that channel. The email OTP variant sends a 6-digit one-time code instead of a link, and you type the code into the same tab you started in. Same idea, different delivery.

How the flow works

Why teams reach for it

There's no password to forget, reset, or leak in a breach — one fewer secret sitting in your database for an attacker to steal. Onboarding is instant, which is exactly right for a low-risk consumer signup where forcing a password on day one just loses people. For plenty of consumer apps, that trade is a genuine win.

The honest caveats

Magic link vs email OTP vs passkey

Where each one fits

Right-size it to the stakes. For low-risk consumer accounts — newsletters, early signup, "just let me read this" — a magic link or email OTP is a friendly, reasonable default, especially as a fallback when a passkey isn't set up yet. But the moment the account holds money, personal data, or admin power, reach for passkeys for real phishing resistance, and keep email as the recovery path you deliberately harden — never the front door you lean on by accident.

Identity verification — proving there's a real person

Logging in proves you can get into an account. It says nothing about who the human at the keyboard really is. For a bank, a marketplace seller, or age-restricted goods, you need to prove the real-world person — that's identity verification.

Authentication is not proofing

Authentication answers "do you hold the credential for this account?" — the password, passkey, or magic link. Identity proofing (also called IDV) answers a different, harder question: "are you genuinely the real-world person you claim to be?" You can perfectly authenticate into an account that was opened under a fake name — the login is flawless and the human is still a fraud. Proofing is the step that ties an account to an actual person, and it belongs at the boundary where that matters. (For the wider "proving who you are" picture, see proving who you are.)

Assurance levels — climb only as high as the risk

Not every account needs a passport check. The NIST 800-63A model captures this with identity assurance levels (IAL) — plain-English rungs from "self-asserted" (you just type your name) up to "remotely verified with a document and a selfie" and finally "verified in person." You match the rung to the risk: low stakes, low rung; regulated money, high rung.

How proofing actually gets done

The document-plus-liveness pair is the workhorse of remote IAL2: the document proves the identity exists, and the liveness check proves the person submitting it is real and present, not a static image scraped from social media. No single method is bulletproof, which is why proofing stacks a few signals together and matches the total to the rung you actually need.

KYC, privacy, and not becoming the breach

The regulated version of all this is KYC/AML — Know Your Customer / Anti-Money-Laundering — the legally-mandated proofing banks and marketplaces must perform (part of the rules of the game). But collecting someone's passport creates a fresh danger: you now hold a folder of exactly what identity thieves want.

Proofing isn't one-and-done either: high-value actions can trigger re-verification, and a mid-session jump in risk should trigger a step-up — the same "climb a rung" idea, applied after login.

The big picture — the death of the lonely password

Maya opened this track locked out again: one password reused across a dozen sites, already sitting in a breach dump, with a lookalike page waiting for her next typo. Eleven lessons later, that lonely password is retired — and what replaced it is both safer and smoother. Let's watch the whole arc as one story before you take the quiz.

The story you just lived

We killed the password first. In passkeys & WebAuthn Maya swapped the shared secret for a key pair that never leaves her device — nothing left to phish, reuse, or spill in a breach. But a device can be lost, so MFA enrollment & factors added a second factor and the golden recovery rule: never gate getting back in on the very thing you may have dropped in the lake. Challenging every login, though, protects no one and annoys everyone — so adaptive risk-based MFA scores each sign-in and only stops the strange ones. And when Maya is about to do something genuinely risky, step-up & assurance demands fresh, recent proof — and makes the API actually verify it came back.

Meanwhile, attackers hammer the front door with millions of stolen passwords. Bot detection & the CAPTCHA handoff makes that automation expensive, while breached-password detection refuses the known sitting-duck passwords — without the site ever seeing the password itself. For Sam's enterprise customers, enterprise SSO & home-realm discovery quietly routes each user to their own corporate login by email domain, so nobody juggles yet another password.

Then the story moves past the login moment, because a sign-in is only the first second — what follows is a session. Sessions, cookies & sign-out is Priya's chapter: three sessions with three lifetimes, and the hard truth that a sign-out is only real if every session that login spawned actually dies. When her native app launches a web page, native-to-web SSO carries the sign-in across that gap with no second login and no shared secret leaking into the browser. For the moments a full login is too heavy, magic links & email OTP trade the password for the inbox — convenient, but with fine print that rests entirely on that mailbox. And when the stakes need the real human and not merely the account, identity verification proves there's a genuine person behind the keyboard. That's the arc: remove the secret, adapt the friction, then extend one trusted sign-in across every surface.

The threads that tie it together

Where these ideas go next

A login's job is to mint credentials — so follow them: Token Security opens up what every one of these sign-ins hands out and how APIs check it. To meet the attacks these defenses answer head-on, adversary-in-the-middle phishing shows exactly what passkeys and step-up are built to beat. And since recovery is the quiet weakest link running under this whole track, account recovery is where to harden it.

Ready to prove it stuck? The cheat sheet & pop quiz is just ahead.

Cheat sheet & pop quiz

Eight lessons on proving who's really there — here's the one-idea-per-lesson distillation, a symptom-to-defense map for when things go wrong, and five scenarios to prove it stuck.

Eight ideas, one per lesson

Symptom → defense — a quick-reference

Pop quiz — five questions

Start here — the life of a token

Once Maya signs in, a small credential is minted that says "this is Maya, and here's what she may do." That credential — the token — is the beating heart of every modern login. This track is its biography: how it's born, how it lives, what happens when a thief grabs it, and how apps decide which parts of it to believe.

Why a whole track about one object

Almost every authentication acronym is just machinery around the token (a story Foundations tells first). Get the token's lifecycle right and most attacks fizzle; get it wrong and a single stolen string becomes a skeleton key. So we follow one from cradle to trusted claim.

The journey

Lesson 1 is birth — how tokens are minted with the authorization-code flow and PKCE, and why OAuth 2.1 killed the old implicit flow. Lesson 2 is a healthy life: rotation, so a leaked refresh token defeats itself. Lessons 3–4 are theft — two layers of defense that make a stolen token first killable, then worthless. Lesson 5 wires tokens into a nervous system with CAEP & Shared Signals, so one alarm logs you out everywhere. Lesson 6 is trust: which claims inside a token you can actually rely on. Then the recap.

1. The birth of a token — auth-code flow & PKCE, and why implicit is dead.
2. Refresh-token rotation — make a leaked refresh token trip its own alarm.
3. Stolen-token defenses I — revoke, expire, and step up so theft is short-lived.
4. Stolen-token defenses II — DPoP, mTLS & encryption make the copy useless.
5. CAEP & Shared Signals — one fraud alert logs you out of every app.
6. Claims you can trust — tell the locked-down facts from the editable ones.
7. Validating a JWT — be the API: verify the seal, then check the claims that decide who gets in.
8. Opaque tokens & introspection — the other kind of access token, and why a random string can be revoked instantly.
9. Cheat sheet & pop quiz — the biography boiled down, then five scenarios.

How to use it

Read one lesson at a time; your progress saves in your browser — no account needed, and signing in syncs it across your devices. Most lessons end with a hands-on lab — you'll mint, rotate, and decode real tokens — and the track ends with a cheat sheet & pop quiz that unlocks after you reveal all five answers.

Every token has a beginning. Start with the birth of a token and follow it from there.

The birth of a token — authorization code & PKCE

Every token has a birthday. Before rotation, before theft, before you personalize a page from its claims — there's the moment an access token and a refresh token first come into existence. Maya taps "Sign in" on her pilates-booking app, and a few seconds of careful choreography hands that app its very first tokens. Let's watch the delivery.

Two channels, one sign-in

The whole flow runs across two very different pipes. The front channel is the browser: redirects Maya can see, bookmark, and — if she's unlucky — leak. The back channel is a direct, TLS-protected, server-to-server call from the app's backend to the identity provider, where no browser can eavesdrop. The golden rule falls straight out of this split: the app's client secret and the real tokens live on the back channel; the front channel only ever carries a disposable stand-in. This is the OAuth 2.1 authorization code flow, and it's the birth certificate for almost every token in the rest of this track.

The authorization code — a one-time claim ticket

Here's the twist beginners never expect: after Maya logs in, the identity provider does not hand the browser her tokens. It hands over a short-lived authorization code — a one-time claim ticket. The backend then redeems that ticket over the back channel for the actual tokens. Three guards protect the ticket in transit:

PKCE — the twist that makes a stolen code worthless

A claim ticket is still a claim ticket: whoever presents it gets the tokens. So what stops a thief who snatches the code off the front channel? PKCE (Proof Key for Code Exchange, RFC 7636). Before it starts, the backend invents a big random secret — the code_verifier — and sends only its SHA-256 hash up front as the code_challenge (method S256). To redeem the code at the token endpoint, it must present the original verifier; the server recomputes SHA-256(verifier) and refuses unless it equals the challenge it stored. The thief has the ticket but never saw the verifier, so their redemption fails with 400 invalid_grant. The stolen code is worthless.

Why OAuth 2.1 retired two old grants

PKCE is now mandatory for every interactive client, and OAuth 2.1 quietly buried two legacy paths that couldn't offer this protection. The implicit grant dumped tokens straight into the browser's URL fragment on the front channel — fast, and hopelessly leaky. The resource-owner password grant had the app collect Maya's actual password and post it onward, which torpedoes SSO, MFA, and any hope of phishing resistance. Authorization code + PKCE replaces both as the single blessed way to log a human in.

Refresh-token rotation & reuse detection

A refresh token is a long-lived master key to your account. So what happens the moment one leaks? With rotation, the answer is delightful: the thief's copy trips the alarm and burns the whole set down.

Two tokens, two jobs

Every login hands your app two things. A short-lived access token — the key you show the API on every call, good for minutes. And a long-lived refresh token — a credential your app quietly trades in for fresh access tokens so you don't have to log in every few minutes. That second one is the crown jewel: whoever holds it can keep minting access to your account. (For the full token tour, see the tokens lesson.)

Rotation makes a leaked token self-defeating

A rotating refresh token is single-use: each time your app refreshes, the identity provider (IdP) returns a brand-new refresh token and invalidates the old one. Now add reuse detection — if the old, already-spent token is ever presented again, the IdP assumes it was stolen and revokes the entire token family (that token and every descendant), forcing a clean re-login.

The leeway window (why it isn't a hair-trigger)

Networks drop responses. If your app's refresh reply gets lost and it legitimately retries, you don't want the whole session nuked. So rotation adds a small leeway — a grace window of a few seconds where the just-rotated token can be replayed once, tolerated as an idempotent retry. A replay after the window trips reuse detection. Keep the leeway tiny: seconds, not minutes.

Stolen-token defenses I — revoke, expire, step up

You hit "sign out everywhere" in a panic. Your session and refresh tokens die instantly — but the access token a thief already copied keeps working until it expires. Here's how the API refuses it anyway.

Why a stolen access token is so stubborn

An access token is a self-contained, signed token (a JWT) that the API trusts without phoning home to the IdP — that speed is the whole point of the design. But it's also why nobody can "un-issue" the copies already out there: the API never asks permission, so a thief's copy sails through until the token's exp (expiry). Three credentials, three very different cancel stories:

Defense 1 — a revocation marker (kill it on the server)

This is the centerpiece — the one defense that truly stops a live stolen token. When you sign out everywhere, the API writes a revocation marker: a cut-off timestamp meaning "everything issued before now is dead." On every call, right after the signature check, the API compares the token's iat (issued-at) to the cut-off. If iat ≤ cut-off, it's refused (token_revoked). A fresh login mints a token after the cut-off, so the gate self-heals for the real you while staying shut for the thief.

Defenses 2 & 3 — shrink the replay window

Defense 4 — sudo re-auth (recent auth_time)

Like sudo on your laptop: even though you're logged in, a privileged action makes you re-prove it's you right now. The API rejects refresh-minted tokens (no human was present) and requires auth_time within a short window. This is about when you last authenticated, not which method — the complement to the step-up above.

Stolen-token defenses II — DPoP, mTLS & encrypted tokens

Last lesson made a stolen token killable and short-lived. This one makes the copy itself worthless — bound to a key the thief doesn't have, or encrypted so they can't even read it.

From bearer to sender-constrained

By default an access token is a bearer token — like cash, whoever holds it can spend it. A sender-constrained token flips that: it's bound to a secret only the legitimate holder possesses, so a copy on its own is inert. The thief can grab the token all day; without the secret, it's a dead number.

DPoP — bind the token to a browser-held key (RFC 9449)

Your browser generates a non-extractable key — a private key WebCrypto will sign with but never hand back, so even malicious JavaScript can't steal it. The token is stamped with that key's fingerprint (cnf.jkt). On every call the browser signs a fresh little proof with the private key; the API checks the proof's key matches cnf.jkt, that it's bound to this method + URL + token-hash, and that its jti (proof id) hasn't been seen before (no replay). A copy without the key fails with jkt_mismatch. This is DPoP (Demonstrating Proof-of-Possession).

Four ways to disarm a copy

Encryption vs sender-constraining — don't confuse them

A normal token is signed, not secret: anyone can base64-decode it and read your email, scopes, and roles. A JWE (encrypted token) fixes confidentiality — it stops a thief reading the token. DPoP and mTLS fix possession — they stop a thief using it. They solve different problems, so a JWE can still be replayed. Layer them: encrypt for privacy, sender-constrain for anti-replay.

Agents leak tokens — so bind theirs too

When an AI agent acts for you, a governance layer mints it an on-behalf-of (OBO) token via token exchange (RFC 8693): the agent's identity, your authority, a narrowed scope. Agent tokens leak easily — they flow through logs, traces, and tool output, and a prompt injection can try to exfiltrate one. So bind the OBO token to the agent's own non-extractable key (cnf.jkt) — the same RFC 9449 mechanism, one level up. A captured copy is then refused with jkt_mismatch.

CAEP & Shared Signals

Rotation and revocation protect one system. But your identity lives across dozens of apps. Shared Signals lets a fraud alert in one instantly log you out of all of them.

The problem — silos don't talk

Your IdP revokes a session, but the SaaS app you signed into 20 minutes ago still thinks you're fine — it trusted your login and won't recheck for hours. Continuous Access Evaluation (CAEP) replaces "trust this login forever" with "keep re-evaluating and react to events in near-real-time." When something changes, downstream systems hear about it and act.

A signed event, passed between trusted systems

The Shared Signals Framework (SSF) is a standard way for a transmitter (an IdP, a fraud service, an ITDR tool) to push security events to receivers. Each event travels as a Security Event Token (SET) — a signed token (RFC 8417) describing what happened: "session revoked," "credential changed," "assurance downgraded." The receiver verifies the signature, finds the subject, and revokes that subject's sessions and refresh tokens everywhere — plus stamps a revocation marker so even the live access token is refused mid-flight.

What triggers a signal

Claims you can trust

Your app reads a token and personalizes everything from it — tier, region, a verified phone. But which of those facts can a user quietly rewrite, and which are locked down? That line is a security boundary.

Personalize from signed claims only

A claim is a fact carried inside a signed token — your name, your tier, your region. Because the IdP signs the token, your app can trust the claim without a database round-trip. The rule that follows is strict: personalize only from signed claims. Never from a query parameter, a header, or localStorage — anything the browser can set, an attacker can set too. (More on token anatomy in the tokens lesson.)

Two kinds of profile data, two owners

Not all profile data carries the same weight. User-writable metadata holds cosmetics — theme, language — that the user sets freely through a self-service API; no security weight, so self-service is fine. Platform-controlled metadata holds entitlements — tier, region, roles — that only a post-login hook or an admin can write. Put anything an attacker would love to set on the platform-controlled side, so a user-facing API is structurally unable to write it.

Promoting a self-asserted fact to a verified one

A self-asserted attribute is one you simply typed — a phone number saved to user-writable metadata. It's unproven, so it's untrusted. A verified attribute is one you proved control of, by entering a one-time code (OTP) sent to the handset. On success it's promoted to platform-controlled metadata and mirrored onto the token as the standard phone_number_verified claim. Only ever send 2FA codes, recovery links, or transaction alerts to a verified number.

Validating a JWT — the checks that actually matter

A JWT lands on your API's doorstep. Before it trusts a single word inside, the API must answer two questions: is this token real, and is it for me? Get that wrong and you haven't built a lock — you've built an open door. Botched validation is one of the top causes of auth bypass, so let's do it right.

Decoding is not verifying

An API's first temptation is to base64-decode the token, read the claims, and get on with its day. That is the trap. Decoding just unpacks the letters — and anyone can write a letter. Verifying proves the issuer actually sealed it. So validating a JWT is two moves, strictly in order: first check the signature, then check the claims. Skip the first and every claim inside is attacker-supplied fiction. (Need the token basics first? See the tokens lesson.)

Step one: verify the signature

The signature is made with the issuer's private key; you check it with the matching public key. Real deployments fetch that key from the issuer's JWKS (JSON Web Key Set) and pick the right one using the token header's kid (key id). The whole trust-anchor story — where the keys live and why you can trust them — is in federation trust. A verified signature means the claims are exactly what the issuer wrote, untampered. Only now are they worth reading.

Step two: the claims that actually matter

Each of these is one quick question. Miss any and the door creaks open.

The aud check is the one teams quietly skip — and it's how a token minted for a different service gets replayed against yours. This is exactly why token exchange re-issues a fresh, narrowly-audienced token instead of forwarding the original: every API should accept only tokens stamped with its own name.

Four famous ways to get robbed

Opaque tokens & introspection — the other kind of token

Not every access token is a JWT you can read. Some are opaque — a random string that means nothing on its own. It's not a document; it's a claim-check ticket. To learn anything about it, the API has to ask the issuer.

Two shapes of the same idea

A JWT access token is self-contained: the claims travel inside it, so the API verifies the signature and reads them locally — fast, no phone call. An opaque token is a reference: a meaningless handle whose real details live back at the issuer. The API can't read it; it must look it up.

Introspection: asking "is this still good?"

To use an opaque token, the API calls the issuer's introspection endpoint — a standard defined by RFC 7662. It sends the token and gets back the truth: active (true or false) plus, if active, the details it's allowed to know — scope, sub (the subject), exp. If active is false, the API stops right there.

The trade-off — and how caching softens it

The split is real. JWTs are fast and offline, but you can't un-issue one — a stolen JWT keeps working until it expires (which is exactly why stolen-token defenses lean on short lifetimes). Opaque tokens give you instant revocation and hide their contents, but every check is a network round-trip and a tighter coupling to the issuer. To cut that cost, APIs cache the introspection result for a short time (a few seconds). Caching buys back most of the speed — but reopens a small revocation gap, because a freshly-revoked token can still ride a warm cache entry until it expires. Short TTL, small gap.

So which do you pick?

Many real systems run both: fast JWTs for internal hops, introspected opaque tokens at the public edge. Either way, the token is still only as safe as the login that minted it — the whole journey started back at the tokens lesson.

The big picture — the life of one token, end to end

You started this track holding a mystery: a small credential is minted at login and somehow every app just trusts it. You end it holding a whole biography. You can now trace one token from the moment it's born, through the rotation that keeps it honest, the theft that tests every defense, and the final gate where an API decides which of its words to believe. This page ties those lessons into a single story so you walk into the quiz with the arc clear in your head.

The story you just lived

It started with a birthday. Maya tapped "Sign in", and over a private back channel a fresh pair of tokens was born — an authorization code redeemed with a PKCE verifier a pickpocket could never guess. From that moment the token had a life to protect. To keep the long-lived refresh token honest, every use rotated it, so the day a thief replayed an old copy the whole family burned down around them.

But an access token already copied keeps working until it expires — so you learned the server-side ways to refuse it anyway: a revocation marker checked on every call, shrunken lifetimes, and a step-up that demands the token itself evidence a second factor. Then you made the copy worthless in the first place, binding it to a key with DPoP or mTLS so a stolen bearer string is a fistful of dead numbers. And because your identity lives across dozens of apps, not one, a single signed signal — CAEP over Shared Signals — turned local revocation into a network-wide kill switch: Zara flags Priya's laptop and every downstream app drops her sessions in seconds.

With the token defended, the question turned inward: which of its claims can you actually believe? You drew the trust boundary — cosmetics a user may scribble, entitlements only the platform may laminate. And when a token finally lands on an API's doorstep, you ran it through the four validation gates — signature, issuer, audience, expiry — because decoding is not verifying and alg:none is not a signature. Last, you met the token's quieter cousin: the opaque token, a claim-check ticket that means nothing on its own until the issuer's introspection ledger vouches for it. Birth, rotation, theft, defense, trust, validation — one object, one lifetime.

The threads that tie it together

Where these ideas go next

A token proves who's asking and how far you can trust it — but not yet what it's allowed to touch; that's scopes and least privilege in the Authorization track. When you're ready to design the numbers yourself, token lifetimes turns these defenses into concrete minutes and rotation windows, and workload identity federation shows how machines can earn tokens with no stored secret at all.

Feeling solid? Time to prove it — the cheat sheet & pop quiz is one page away.

Cheat sheet & pop quiz

Five lessons on keeping tokens honest — here's the whole track boiled down to a cheat sheet, an attacker-to-defense lookup, and five scenarios to prove it stuck.

Eight ideas that harden every token

The attacker got X → your defense is Y

Pop quiz — five questions

Start here — who can do what

Authentication answers who you are. This track answers the other, larger half: what you may do — and it's where identity meets your real API estate. Priya proved she's Priya at the door; now every request she makes has to be checked against what she's actually allowed to touch. That check is authorization, and getting it wrong is how APIs get breached.

The bridge track

Everything you've learned about proving identity is worth little if the app then lets anyone read anyone's data. Authorization is the enforcement half, and it lives right at your APIs. This track is the bridge from the identity tracks to the real-world services that face the internet — building on zero trust and laying the groundwork for the AI track's take on fine-grained access.

The journey

Lessons 1–3 build the decision itself: the access models (RBAC, ABAC, ReBAC), modeling permissions as a graph, then externalizing decisions as policy-as-code. Lesson 4 covers scopes, consent, and least privilege by design. Then the API side: lesson 5 chooses a credential, lesson 6 enforces at the gateway, and lesson 7 tours how APIs actually get broken. Lesson 8 is the recap.

1. RBAC, ABAC & ReBAC — the three ways to answer "who can do what."
2. Permissions as a graph — model real-world sharing with relationships.
3. Policy as code — externalize decisions so apps stop hard-coding rules.
4. Scopes & consent — least privilege designed into every grant.
5. API keys vs OAuth — choose the right credential for the caller.
6. The API gateway — enforce identity and policy at the front door.
7. OWASP API Top 10 — a guided tour of how APIs actually break.
8. Cheat sheet & pop quiz — the whole track distilled, then five scenarios.

How to use it

One lesson at a time; your progress saves in your browser — no account needed, and signing in syncs it across your devices. Most lessons end with a hands-on lab where you'll write policies and break (then fix) an API, and the track closes with a cheat sheet & pop quiz that unlocks after all five answers are revealed.

Authentication got you in the door. Now learn what happens next — start with RBAC, ABAC & ReBAC.

Who can do what — RBAC, ABAC & ReBAC

Authentication proves who Maya is. Authorization decides what she may do — and that turns out to be the harder, messier half. There are three big ways to answer it, and every real system ends up blending them.

Picture one running scene: a shared document workspace. Maya is a customer, Sam is an outside partner, Priya works in finance. The question on the table never changes — "Can Sam edit doc:report?" — but each model reaches its answer by a completely different route.

RBAC — access by the hat you wear

Role-based access control (RBAC) groups permissions into roles, then hands roles to people. Priya gets editor; Maya gets viewer; Sam gets nothing until someone grants it. Clean, auditable, and everyone understands it — which is exactly why it's everywhere.

The failure mode shows up when reality refuses to fit tidy roles. Priya doesn't need "editor" — she needs "editor, but only finance documents, only in EMEA, only while she's covering a leave, and only this quarter." So a role is born: editor_finance_emea_temp_v2. Then another. This is role explosion — hundreds of hyper-specific roles nobody dares delete, because nobody remembers who'd break.

ABAC — access by the rules of the moment

Attribute-based access control (ABAC) throws out fixed rings and writes rules over attributes instead: facts about the user, the resource, and the context. "Allow edit if user.department == resource.department and user.clearance >= resource.classification and the local time is business hours." Priya's finance edit just falls out of the rule — no bespoke role required.

ABAC is enormously expressive, and it shines when decisions depend on live context like time of day, device posture, or data sensitivity (the same signals zero trust leans on). Its ache is the reverse question. RBAC can answer "who can edit this?" by reading a list; ABAC often can't, because the answer is "whoever satisfies the rule right now" — you'd have to evaluate every user against every attribute to enumerate it. Great at deciding, awkward at auditing.

ReBAC — access by how things connect

Relationship-based access control (ReBAC) answers with a graph of relationships: Maya is the owner of doc:report; the report lives in folder:q3; Maya clicked "share with Sam as editor." Now Sam can edit — not because of a role or a rule, but because a relationship edge exists. This is the familiar docs-app "share" button modeled as an authorization system, and it inherits naturally: grant access to the folder and every document inside comes along.

So which one?

Reach for RBAC for coarse, stable, job-shaped access ("engineers can deploy"). Reach for ABAC when the decision genuinely depends on live context and data attributes. Reach for ReBAC when access is about ownership and sharing between specific users and specific resources — the shape most products actually have. Nearly every mature system blends all three: RBAC for the org chart, ABAC for the guardrails, ReBAC for the sharing.

The next lesson dives into modeling that relationship graph, and fine-grained authorization in practice shows ReBAC guarding real product data.

Modeling permissions as a graph

Relationship-based access is only as good as the graph you draw. This is the modeling craft: turning "Maya owns it, the folder holds it, Sam was shared in" into a handful of facts a machine can walk in microseconds — with the fewest edges that still get every answer right.

The vocabulary, borrowed from open source

The open-source OpenFGA project (and the Zanzibar paper behind it) gave this modeling a clean, vendor-neutral vocabulary. A type definition declares a kind of object and the relations it supports: a document has owner, editor, viewer; a folder has parent and viewer. Nothing is granted yet — this is just the schema, the shape of the world.

Access itself is stored as relationship tuples: tiny facts of the form (subject, relation, object). (user:maya, owner, doc:report) means "Maya owns the report." (user:sam, viewer, doc:report) means "Sam was shared in as a viewer." Each tuple is one edge in the graph. Authoring access is writing tuples; revoking is deleting them.

Computed and inherited relations do the heavy lifting

You could write a viewer, editor, and owner tuple for every user — but that's the tuple-explosion cousin of role explosion. Instead, computed relations let stronger relations imply weaker ones: owner ⇒ editor ⇒ viewer. Store only (user:maya, owner, doc:report) and Maya automatically checks out as editor and viewer too. One fact, three answers.

Inherited relations flow across objects. Declare "a folder's viewer is also a viewer of every document whose parent is that folder," and now (folder:q3, parent, doc:report) plus (group:finance#member, viewer, folder:q3) means the whole finance team can read doc:report — without a single tuple naming the document. Note the subject there is a userset (group:finance#member): grant to the group, not to each person, so a new hire reading everything is one membership edge, not fifty grants.

Asking the graph questions

Two questions matter. Check asks a yes/no: "Can Sam view doc:report?" — the engine walks edges until it finds a path or gives up. List-objects asks the enumeration RBAC was good at and ABAC was bad at: "Which documents can Sam view?" Because the answer is a graph traversal, ReBAC handles both directions well. When a rule needs a fact that isn't stored — "is this request from a trusted network right now?" — a contextual tuple is passed in at check time, true only for that single call, never persisted.

Policy as code — externalizing decisions

Somewhere in every codebase lives an if (user.role == "admin" || ...) that no auditor has ever seen and no security team can change without a deploy. Policy as code drags those decisions out of the source and into a place you can review, test, and roll back like any other software.

The sin: authorization scattered through the app

When authorization lives as if-statements sprinkled across handlers, three bad things follow. It's unauditable — no one can answer "what are all our access rules?" without grepping the repo. It's inconsistent — the billing service and the reports service drift into subtly different rules for the same question. And it's unchangeable without a redeploy — tightening one rule means a code change, a review, a release train. Priya's urgent "revoke contractor access to restricted files" becomes a two-week ticket.

The fix: separate deciding from enforcing

The pattern splits one job into two roles. The Policy Enforcement Point (PEP) lives in your app or gateway: it intercepts the request and asks, then obeys the answer. The Policy Decision Point (PDP) is a separate engine that holds all the rules and answers "allow" or "deny." Your code stops deciding and starts asking — "PDP, may Priya delete doc:report?" — and the rules live in exactly one governed place.

OPA and Rego — rules that behave like code

The open-source Open Policy Agent (OPA) is a general-purpose PDP, and Rego is the language you write policies in. The point isn't the syntax — it's that a policy is now a versioned file. It's reviewed in a pull request. It's tested with unit tests ("this request should be denied") that run in CI. And if a change misfires, you roll it back like any other commit. Authorization becomes a first-class engineering artifact instead of tribal knowledge buried in handlers.

Bundles at the edge, logs as the trail

Asking a remote server on every request would be slow, so policies are compiled into a policy bundle and distributed to a sidecar PDP running right next to each service. Decisions are then local and take microseconds — no network hop on the hot path. Meanwhile every decision the PDP makes is written to a decision log: who asked, about what, and the answer. That log is your authorization audit trail, and it feeds straight into identity telemetry & SIEM as one of the richest signals you own.

Scopes, consent & least privilege by design

Every API you publish has a permission surface — the menu of things a client can ask to do. Design that menu well and least privilege is the easy default; design it lazily and every integration becomes over-privileged the day it ships. This is the craft of scopes and consent.

Scopes are the contract

A scope is a named permission a client requests and a user (or admin) grants — bookings:read, payments:charge. A good naming taxonomy reads like resource:action, so the token itself becomes legible: anyone can see that profile:read is far tamer than admin:*. The design tension is granularity. Coarse scopes (account) are easy to request but hand over far too much; fine scopes (bookings:read) map cleanly to least privilege but multiply in number. Aim for scopes that match the real jobs clients do — no broader.

Consent is a security artifact, not a speed bump

The consent screen is where authorization meets UX. It's the user's one chance to see exactly what they're handing over — so a bloated scope list isn't just poor manners, it actively tanks conversion and trains users to rubber-stamp. The fix is incremental consent: ask for the minimum to start, then request more at the moment a feature needs it. The app gets Maya in the door with bookings:read, and only asks for payments:charge when she actually checks out — in context, when the request obviously makes sense.

Audience keeps a token where it belongs

A stolen or over-shared token shouldn't be a skeleton key. Audience restriction (the aud claim) binds a token to a specific API: a token minted for the Bookings API is rejected outright at the Payments API, even if the scopes would otherwise fit. Design each API to check that it is the intended audience, and one leaked token can't roam your whole estate. (Which facts in a token a client can trust — and which it must never rewrite — is the subject of claims you can trust.)

When scopes are too blunt — RAR

Some permissions can't be captured by a static scope. "Charge this card" is a scope; "transfer up to $50 to this specific account" is not — no reasonable taxonomy has a transfer:50:to-acct-8842 scope. Rich Authorization Requests (RAR, RFC 9396) solve this by letting the client send a structured authorization_details object describing the exact action, with limits and targets, and the user consents to that specific thing. It's least privilege taken to its logical end: not "may charge payments" but "may charge exactly $50 to exactly this payee, once." RAR also underpins human-in-the-loop approvals for agents, and pairs with delegated third-party access where a token must be scoped to one narrow task in someone else's system.

API keys vs OAuth — choosing your credential

Bot A has to call the billing API at 3 a.m. with no human around to type a password. What credential does it carry? The lazy answer is a static API key. The safer answer is a short-lived token — and the difference only becomes obvious the day the credential leaks.

The static API key — easy today, sorry later

A static API key is just a long random string you paste into a request header. It's wonderfully easy: no dance, no expiry, no library. That ease is also the whole problem. It never expires, so a copy is valid forever. It carries no identity beyond "whoever holds this string" — the server can't tell Bot A from a thief. It has a way of ending up in a repo, a CI variable, a screenshot, a Slack thread. And when you finally have to change it, rotation is a fire drill: every caller breaks at once unless you carefully overlap old and new. Non-human identities like Bot A already outnumber your people (see non-human identities) — handing each one an immortal secret does not scale.

OAuth client credentials — expiry as the safety net

The standards answer is the client credentials grant (OAuth 2.1). Bot A authenticates once to the token endpoint and receives a short-lived, scoped access token — good for minutes, not forever. Three things change instantly. Expiry becomes your safety net: a leaked token is worthless once it ages out, the same principle that makes rotation work for humans (refresh-token rotation). Attribution arrives for free — every token carries a client_id, so logs can name the caller. And central revocation means one switch at the authorization server cuts Bot A off everywhere, no scavenger hunt through config files.

Beyond shared secrets — proving identity without one

Even a short-lived token starts from a client secret Bot A had to store somewhere. You can remove the shared secret entirely. With mTLS or private_key_jwt client authentication, Bot A holds a private key and proves possession of it — the secret never travels the wire, so it can't be sniffed or logged. Better still, workload identity (the SPIFFE model) has the platform itself vouch for the workload: Bot A is minted a short-lived identity document at runtime because of where and what it is, so there's no long-lived secret to leak at all.

The API gateway — enforcement at the front door

Every request to every API in your estate should walk through one guarded front door before it touches a single service. That door is the API gateway — and it's where you stop trusting the network and start verifying each call.

The gateway is your policy enforcement point

In policy-as-code terms (from policy as code), the gateway is the policy enforcement point (PEP) for your whole API surface: the chokepoint that asks the question and applies the answer on every request. Because it sees all north-south traffic — clients on the outside talking to services on the inside — it's the one place you can enforce a rule once and have it hold everywhere. Without it, every service re-implements token checks and rate limits in its own way, and the weakest implementation becomes the way in. Maya's app, Bot A, and a partner's integration all knock on the same door, and the door treats none of them as trusted until it has checked.

What the door checks, in order

The candy-shell anti-pattern

Here's the trap: teams build a crunchy edge and a gooey center. The gateway checks everything, so the services behind it trust anything that got through — no auth, no identity, plain HTTP on a "private" network. One foothold inside and an attacker moves freely. Zero trust (from zero trust & context) says re-verify inside too: put mTLS and service identity on the east-west traffic between services, so each one proves who it is to the next. The gateway guards the front door; the mesh means every interior door is locked as well.

How APIs get broken — the OWASP API Top 10 tour

Most API breaches aren't clever cryptography — they're an authorization check that was simply missing. Let's tour the identity-flavored entries of the OWASP API Security Top 10 (2023) as attack stories against one small system: Maya's pilates-booking API.

#1 — Broken Object Level Authorization (BOLA)

The number-one API risk, and the simplest. Maya's app fetches her booking at GET /bookings/1001 and it works. So the attacker changes one digit — GET /bookings/1002 — and reads Sam's booking, name, phone and all. The API checked that the token was valid; it never checked that this caller owns this object. The fix is a per-object authorization check on every request — exactly the relationship question a graph answers well (see modeling permissions as a graph): does Maya own booking 1002? No → 403.

#2 — Broken Authentication

If tokens can be forged, guessed, or never expire, everything above collapses. Weak signing, missing expiry, no audience check — the birth and validation of a token is its own discipline (see how tokens are born). Get authentication wrong and the attacker doesn't need to swap object IDs; they just mint whatever identity they like.

#3 — Broken Object Property Level Authorization

Maya updates her profile with PATCH /users/me {name: "Maya"} — fine. But the endpoint blindly binds every field in the body to the record, so the attacker sends {role: "admin"} and promotes themselves. This mass assignment flaw is about which properties a caller may write: name yes, role never. The fix is an explicit allow-list of writable fields, server-side.

The rest of the tour

Each break → the defense in this academy

The big picture — deciding what, from model to front door

Authentication answered a single word: who. This whole track answered the larger, messier half — what — and it's where identity stops being a login screen and becomes your real API estate. You started by choosing how to even phrase the question, and you finished by touring how every answer gets broken in the wild. This page threads those seven lessons into one story so the arc is clear before the quiz.

The story you just lived

Priya proved she was Priya at the door — and then the real work began. First you learned there isn't one way to answer "what may she do" but three, and every real system blends them: RBAC, ABAC and ReBAC — a role, a rule, or a relationship. When access is really about this person and this thing, relationships win — so you learned to model permissions as a graph, the fewest edges that still answer every check, letting Sam inherit a viewer role he was never granted directly.

Those rules had been hiding in scattered if-statements no auditor ever saw, so you dragged them out into policy as code — a bouncer that only enforces and a guest list that management rewrites without a redeploy. Then you designed the permission surface itself: scopes, consent and least privilege by design, where Maya reads a greedy consent screen and taps Deny. You gave the machines credentials too, weighing a static API key against a short-lived token — the house key you can't un-cut versus the keycard that dies at checkout.

With models chosen, rules externalized and grants scoped, you put every request through one guarded front door — the API gateway — refusing to trust the network and mistrusting any candy-shell with a gooey center. And finally you toured how all of it breaks: the OWASP API Security Top 10, where Maya changes one digit in a URL and reads Sam's booking, because the object-level check "is 1002 hers?" was simply never made. Model, graph, policy, scope, credential, gateway, and the one missing check — that's the shape of authorization done right, and the shape of every breach when it isn't.

The threads that tie it together

Where these ideas go next

The same permission graph you drew here reappears guarding AI: fine-grained authorization for agents walks a ReBAC model to keep an AI out of data it shouldn't see. Authorization across microservices scales the gateway-and-policy pattern to a whole estate, and consent phishing shows the dark mirror of the very consent screen you learned to design well.

Think it stuck? Put it to the test — the cheat sheet & pop quiz is one page away.

Cheat sheet & pop quiz

Seven lessons on deciding who may do what — here's the whole track boiled down to a cheat sheet, a "which tool for which job?" lookup, and five scenarios to prove it stuck.

Seven ideas that decide every request

Which authorization tool for which job?

Pop quiz — five questions

Start here — your map of the protocol zoo

Every other track told you what a login proves and why a token is safe. This one finally pulls back the curtain on the how: the actual messages — every redirect, every POST, every signed blob — that fly between your app and an identity provider the instant Maya clicks "Log in." It looks like magic. It's really just a handful of well-choreographed conversations, and by the end of this track you'll recognize each one on sight.

The track that shows you the wire

A protocol is simply an agreed set of messages: who says what, in what order, so two systems that have never met can still trust each other. An identity provider (IdP) is the service that logs users in; your app is the relying party that trusts it. This track walks the real exchanges behind that trust — and the new Flow Explorer on the hub plays each one back like a film, step by step, so you can watch a message leave one actor and land on the next.

The journey

Lessons 1–2 cover human logins on the two protocols that run the world: modern OIDC and the enterprise veteran SAML. Lessons 3–4 handle logins with no human at the keyboard — a backend robot, then a TV. Lesson 5 is honest delegation: one service acting for a user without pretending to be them. Lesson 6 is what happens the first time someone new shows up. Lesson 7 is the invisible plumbing — how an app it's never met knows where to send Maya and whose signature to trust. Lesson 8 ties a bow on all of it.

1. Anatomy of a login — every message behind the "Log in" button, in order.
2. SAML — the enterprise workhorse that still speaks signed XML.
3. Machine login — client credentials, for robots with no human behind them.
4. Device flow — signing in a TV or gadget that has no keyboard.
5. Token exchange — honest delegation: acting for a user, never as them.
6. JIT provisioning & account linking — first arrivals and two-door accounts.
7. Federation trust — metadata, keys & discovery: the plumbing that makes it all safe.
8. Cheat sheet & pop quiz — the whole zoo distilled, then five scenarios.

How to use it

One lesson at a time; your progress saves in your browser — no account needed, and signing in syncs it across your devices. Most lessons end with a hands-on lab where you'll step through the flow yourself, and the track closes with a cheat sheet & pop quiz that unlocks after all five answers are revealed. No prior knowledge assumed — every term is defined the first time it appears.

Enough theory from the other tracks — let's watch the wire. Start with Anatomy of a login.

Anatomy of a login — the auth-code flow up close

Maya clicks "Log in", and 0.8 seconds later her dashboard appears. It feels like one click. It's actually a tiny, carefully choreographed dance between three parties — and once you can see the steps, logins stop being magic and start being obvious.

Two lanes: the front channel and the back channel

The whole flow runs across two very different roads, and telling them apart is the key that unlocks everything else.

The front channel is anything that travels through Maya's browser — clicks, page redirects, URLs. It's convenient (the browser carries messages between the app and the identity provider for you), but it's visible and tamperable: Maya, her browser extensions, and anything watching the address bar can read it, and a clever attacker can try to bend it.

The back channel is a direct, server-to-server conversation between the app's own server and the identity provider (IdP) — the service that actually checks who you are. No browser in the middle. It's private: outsiders can't see it and can't touch it. Secrets belong here.

The /authorize request and its cast of parameters

Step 3 is the app sending Maya (via her browser) to the IdP's /authorize address, carrying a handful of parameters. Each one has a job:

Why the code is worthless if stolen

At step 4 the IdP hands back an authorization code — a short random string — through the browser, right out in the visible front channel. That sounds alarming until you see how little a thief can do with it. The code is single-use (redeemed once, then dead), it lives for seconds, and to trade it for tokens at /token the app must also present the PKCE secret — the code_verifier — that matches the code_challenge from step 3. That secret never left the app's server. So a stolen code arrives with no verifier and, usually, already spent. This is the PKCE story told in full in the birth of a token.

Two tokens, two audiences

Step 7 returns not one token but two, and the difference is simply who each one is talking to.

Mix these up and you get bugs and vulnerabilities: sending an access_token where an id_token belongs, or trusting an id_token to authorize an API call. Audience is the whole point. After step 7 the app drops a session cookie and Maya's dashboard loads — what that cookie does next is the sessions & sign-out lesson.

SAML — the enterprise SSO workhorse

Priya signs in to her company portal once in the morning, and every work app just lets her in for the rest of the day. The quiet protocol behind that is SAML — an XML-era design that still runs half the business world's single sign-on. It looks old-fashioned, and it is; it also works, everywhere.

What SAML actually moves: an assertion

SAML (Security Assertion Markup Language) is a standard for one system to tell another "I checked this person, and here's what I know." The message it sends is a SAML assertion: a signed statement, written in XML, that says something like "This is Priya, verified at 09:14, a member of Finance." The signature is what makes it trustworthy — change one byte and the signature breaks.

Two roles: the SP and the IdP

SAML has exactly two parties. The Identity Provider (IdP) is where Priya actually logs in — it holds the passwords and does the checking. The Service Provider (SP) is the app she wants to use — it trusts the IdP to vouch for her instead of running its own login. Priya's mail app, expense tool, and HR portal are all SPs pointing at the one company IdP. That's what "single sign-on" means: one login at the IdP, accepted by many SPs. (The wider picture of routing a user to the right IdP is enterprise SSO & home-realm discovery.)

Trust is set up once, then assertions flow forever

Before any of this works, the SP and IdP must agree to trust each other. They do it with a one-time metadata exchange: each side hands the other a small file listing its certificates (so signatures can be verified) and its endpoint URLs (where to send requests and responses). Set that up once, and from then on assertions flow between them without any further setup.

SP-initiated vs IdP-initiated — and RelayState

There are two ways a SAML login can start. In SP-initiated login, Priya goes to the app first; the SP sends her to the IdP with a request, and later matches the answer to that request. In IdP-initiated login, she starts at a company launchpad and clicks an app tile; the IdP fires an assertion at the SP with no prior request to match.

SP-initiated is the preferred one, for a simple reason: because the SP made a request, it has something to correlate the response against (via an InResponseTo value), which shuts the door on assertions being replayed or injected out of nowhere. IdP-initiated has no such anchor. To send Priya back to the exact page she wanted — the deep link — SP-initiated login carries a RelayState: a small breadcrumb the SP hands over and gets back, so she lands on the expense report she clicked, not a generic home page.

What the SP checks before it trusts the assertion

When the assertion arrives, the SP doesn't just believe it. It runs a validation checklist first.

SAML or OIDC — which, when

SAML isn't wrong, it's just from an earlier era. Here's the honest guide.

Machine login — client credentials

It is 2 a.m. Bot A has to download last night's invoices, and there is not one human awake to click "yes". So the bot does something people never do: it logs in as itself.

Nobody to ask, nobody to redirect

Most logins you have met so far bounce a person through a browser: type a password, tap a passkey, approve a prompt. That whole dance assumes there is a human standing there. A background job has no browser and no human — so it uses a different door.

That door is the client_credentials grant (part of OAuth 2.1). In plain words: the software proves who it is and gets a token for itself. There is no user in the picture, so the client is the subject — the token is about the bot, not about a person acting through the bot.

This is also why a machine login has no consent screen. A consent screen exists to ask a human "do you allow this app to act for you?" With client credentials there is nobody to ask — so nothing pops up, and nothing should. (Bot A is one of the non-human identities we met in the NHI lesson; this is the login it uses.)

Why there's usually no refresh token

When a person logs in, the app is handed a long-lived refresh token so the human doesn't have to re-authenticate every few minutes. A bot doesn't need that crutch. If its access token expires, it simply runs client_credentials again and gets a fresh one — it holds its own credential, so it can ask any time. Handing a bot a long-lived refresh token would just be one more powerful secret to lose. So machine logins typically skip it: short access token, ask again, done.

The credential ladder: three ways to prove you're the machine

"The bot proves who it is" — but how? There are three common ways, and they are not equal. Think of them as rungs on an assurance ladder: each higher rung keeps the real secret further from the wire.

Scope it to the one job

Bot A reads invoices. That is all it should be able to do. When you register the machine client, give its token the narrowest scope that gets the job done — invoices:read, not invoices:read invoices:write admin. Then if the token ever leaks, the blast radius is one read-only job, not your whole billing system. (Choosing between this kind of credential and a plain API key is its own decision — see API keys vs OAuth.)

Where it all goes wrong

The device flow — signing in a TV

Maya's new TV wants her streaming account. Typing a password one letter at a time with a remote is misery — so the login is split in two: the TV shows a short code, and her phone does the real signing in.

Two codes, two jobs

The trick has a standard: the device authorization grant (RFC 8628), better known as the device flow. It exists for gadgets with a screen but no comfortable keyboard — TVs, consoles, printers, smart speakers. Instead of making the low-trust gadget handle a password, it hands the hard part to a device Maya already trusts: her phone.

When the TV starts, the identity provider gives it two codes with very different jobs:

The polling etiquette

While Maya fumbles for her phone, the TV is polling — asking the token endpoint again and again. There are firm manners here, because a badly behaved TV that hammers the server every millisecond is its own kind of attack. The provider's answers tell the TV exactly how to behave:

Why this is safer than typing a password into a TV

The whole point is trust placement. A TV is a low-trust device: shared living-room hardware, rarely patched, easy to shoulder-surf. You do not want Maya's password living there, even for a second. The device flow guarantees it never does — her credential is only ever entered on her phone, a device she controls and that can hold a passkey. (For the flip side, where a trusted native app hands a session to the web, see native-to-web SSO; for the phishing-resistant login her phone should use, see passkeys & WebAuthn.) The consent screen on her phone also names the device — "a Smart TV wants access to your playlists" — so Maya can spot a request she never started.

Token exchange — delegation across services

Maya asks an app to email her a report. Simple — except the app can't build that report alone; it has to call a separate reports service to fetch the data. So which credential does the app show that service? Get this wrong and your audit log starts telling comfortable lies.

The lazy shortcut: forward Maya's token everywhere

When Maya signs in, the app receives an access token — a short-lived key that proves "Maya is here, and she allowed this app." The tempting move, when the app needs to call the downstream reports service, is to just forward that same token. It's already in hand; why mint a new one? Because that token was minted for the app, not for the reports service — and pretending otherwise breaks three things at once.

Three things go wrong

The honest way: RFC 8693 token exchange

Token exchange (RFC 8693) is a small, standard OAuth request that fixes all three. Instead of forwarding Maya's token, the app hands it to the identity provider (IdP) as a subject_token and asks: "give me a new token, scoped for the reports service, for this action." The IdP returns a fresh token that is right-sized on every axis — correct audience, minimal scope, and an honest record of who is really calling.

The key new ingredient is the act (actor) claim. sub still says Maya — this is her data and her request. But act now names the app as the party actually making the call. The log finally reads the truth: "the app, acting for Maya, read report 4411." Chain a third hop and the actor claims nest, so the whole call path is recorded.

Delegation vs impersonation

That act claim is the line between two very different things. Delegation means the app acts for Maya and admits it — both identities visible in the token. Impersonation means the app pretends to be Maya — her identity only, the app erased. Forwarding her raw token is impersonation by accident: nothing records that a middleman was involved.

Where this bites: chains and agents

Two places make token exchange non-optional. First, microservice chains: a request that hops through five services should narrow at every step, each hop trading down to exactly the audience and scope the next one needs — never forwarding a fat token deeper into the system. Second, AI agents. When Kai the agent calls a tool for Priya, the token must carry both of them, which is precisely the on-behalf-of pattern from the AI agents lesson — built on this same RFC 8693 exchange. And because exchange lets you request a narrower scope than the input token, it's the enforcement point for the least-privilege thinking in the scopes lesson.

JIT provisioning & account linking

Sam's partner company just got single sign-on access to your app. Sam clicks "sign in," authenticates at his own company's IdP, and lands on your doorstep — where your app has never heard of him. No account, no record, just a signed assertion saying "this is Sam." Now what?

First login, no local account: three answers

The moment a federated user arrives for the first time, your app faces a fork. There are exactly three sane ways to handle "I don't know you yet."

The sequel problem: account linking

JIT solves the first arrival. But now a subtler question appears: what if the same human arrives through two different doors? Priya signed up months ago with an email and password. Today her company rolled out SSO, and she signs in through the new federated door. Same person, two logins. Account linking is the act of recognizing that and joining them into one account — so she doesn't end up with a split identity and half her stuff in each.

The whole question is: link by what? What signal proves these two logins are the same person? The obvious answer — "they have the same email address" — is also the dangerous one.

The account-takeover trap

The fix is to demand proof before joining accounts. Two safe patterns:

JIT's blind spot: it creates but never deletes

One last catch. JIT provisioning is great at the joiner moment and completely absent at the leaver one. It springs an account into being at first login — but nothing tells it when that person leaves the partner company. So dormant accounts quietly pile up: real, still-valid logins for people who no longer belong. This is exactly the identity lifecycle gap — provisioning without deprovisioning — and the reason JIT shops lean hard on periodic access reviews to sweep out accounts that no longer map to a live human.

Federation trust — metadata, keys & discovery

Maya's app has never spoken to her company's identity provider before. Yet a second after she clicks "Log in," it knows exactly where to send her, and — when a signed token comes back — exactly which key to check the signature against. Nobody hand-configured any of it. This lesson is the quiet machinery that makes that possible: discovery, published keys, and one string you must never get wrong.

The business card: OIDC discovery

An identity provider (IdP) publishes a machine-readable "business card" at a fixed, predictable address. Your app fetches GET https://issuer/.well-known/openid-configuration and gets back a small JSON document — the discovery document — that answers every question an app could ask. Where do I send the user to log in? That's authorization_endpoint. Where do I swap a code for tokens? token_endpoint. Where are the public keys that verify signatures? jwks_uri. And who is this issuer, officially? issuer. Point an app at one URL and it configures the rest of the conversation by itself.

The keys: JWKS and the kid

Tokens are signed so nobody can forge them (see claims you can trust). To check a signature you need the IdP's public key — and the IdP publishes those at its JWKS (JSON Web Key Set) endpoint, the address named by jwks_uri. The catch: an IdP usually publishes several keys at once. So which one signed this token? Every key carries a kid (key id), a short label. Every token's header carries a matching kid. Your app reads the header's kid, looks up the key with the same kid in the set, and verifies with that one. No guessing, no trying every key.