IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Cheat sheet & pop quiz
Here is one idea per lesson. Then comes a map from attack to defense. Last, five scenarios show what stuck.
One idea per lesson
| # | If you remember nothing else… |
|---|---|
| 1 | Tokens are born in the OAuth authorization-code flow. The browser carries only a one-time code. PKCE (S256) ties that code to a code_verifier. A stolen code fails with invalid_grant. The implicit and password grants are gone (getting a token). |
| 2 | An ID token is for the app. It says who signed in. An access token is for the API, and aud names the API. The API rejects any token with another aud or without typ: at+jwt. Never send an ID token to an API (ID tokens vs access tokens). |
| 3 | Make a leaked refresh token defeat itself. Single-use rotation plus reuse detection cancels the whole token family (invalid_grant). See rotation. |
| 4 | You cannot take back a stolen access token. It works until exp. A revocation marker refuses any token with iat at or before the cut-off (token_revoked). A freshness gate and sudo re-auth (a recent auth_time) shrink the window. Step-up checks that the token shows MFA (amr has mfa). If not, the API answers 401 insufficient_user_authentication. See defenses I. |
| 5 | Sender-constrain to make the copy useless: DPoP (cnf.jkt) or mTLS (cnf.x5t#S256). A copy without the key is refused. Encryption (JWE) stops reading, not using. Use both (defenses II). |
| 6 | Turn local canceling into a network kill switch. CAEP over Shared Signals sends a signed SET from a transmitter to receivers. The person is canceled everywhere (CAEP & Shared Signals). |
| 7 | Personalize from signed claims only. Keep entitlements platform-controlled and cosmetics user-writable. Verify facts such as phone_number_verified before you trust them (claims you can trust). |
| 8 | Check a JWT signature first, then claims: iss, aud and exp/nbf. Reject alg:none and pin the algorithm. Take keys only from your own JWKS. Never trust a token you only decoded (validating a JWT). |
| 9 | A JWT is checked on the spot. It is fast, but valid until exp. An opaque token is a reference. The API asks the issuer (introspection) and gets instant canceling. A short cache lowers the cost but leaves a small gap (opaque tokens). |
The attacker got X, so your defense is Y
| The attacker got… | …your defense is |
|---|---|
| A one-time authorization code | PKCE: they lack the verifier, so the swap fails (getting a token) |
| A stolen refresh token | Single-use rotation and reuse detection: the replay cancels the whole token family (rotation) |
| A stolen but unexpired access token | Short expiry, a revocation marker, a freshness gate and step-up (defenses I) |
| A token replayed from their own machine | Proof of possession: DPoP or mTLS tie it to a key they lack. They get invalid_token (defenses II) |
| A token they can read to collect claims | Encrypt it: a JWE is unreadable to the holder, and only the API can open it (defenses II) |
| A hacked session across many apps | A CAEP session-revoked signal (a signed SET) drops the person at every receiver (CAEP & Shared Signals) |
| A self-given or forged claim | Signed claims plus platform-controlled metadata. Self-service cannot write it, so 403 trust_boundary (trusted claims) |
| An ID token replayed as a bearer token | Check aud and typ: at+jwt. The API refuses a token that is not made for it (ID tokens vs access tokens) |
A forged JWT (alg:none, wrong audience) | Pin the algorithm, verify the signature, check iss, aud and exp (validating a JWT) |
Pop quiz: five questions
Q1 · Malware copies Maya's refresh token RT0. Her app refreshes, so RT0 becomes RT1. Later the attacker replays the stolen RT0. What happens?
The IdP sees reuse. The already-used RT0 sets off the alarm. The IdP cancels the whole token family, RT1 too (invalid_grant). Maya and the thief are both logged out. She signs in again, and the thief is locked out (refresh-token rotation).
Q2 · Priya presses "sign out everywhere". A thief already copied an access token that has not expired. Her session and refresh tokens die at once. How does the API still refuse the live access token?
It uses a revocation marker. Sign-out writes a cut-off time. On every call, right after the signature check, the API refuses any token whose iat is at or before the cut-off. The answer is 401 token_revoked. No call to the IdP is needed. A fresh login makes a token after the cut-off, so the real Priya can sign in again (stolen-token defenses I).
Q3 · Kai, an AI agent, acts for Maya with an on-behalf-of token from token exchange. The token leaks through tool output and logs, and an attacker replays it. Why does it fail?
The token is tied to the agent's own non-extractable key (cnf.jkt) through DPoP. Every call needs a fresh signed proof from that key. The copy has no key, so it is refused with invalid_token. The stolen token buys the attacker nothing (stolen-token defenses II).
Q4 · Zara sees Sam's partner laptop flagged as hacked in the SIEM. She needs every app, not only her own IdP, to drop Sam's sessions within seconds. What does that?
CAEP over the Shared Signals Framework. Her ITDR tool, as a transmitter, sends every receiver a signed Security Event Token (SET) that says "session revoked". Each receiver checks the signature and deletes Sam's sessions and refresh tokens. It also writes a revocation marker, so even a live access token is refused (CAEP & Shared Signals; revocation markers).
Q5 · Maya sends the preferences API PATCH {tier: "gold"} to give herself a paid plan. The backend answers 403 trust_boundary. Why, and where should tier live?
The plan is an entitlement. It lives in platform-controlled metadata. Only a login hook or an admin can write it, so the self-service API cannot set it. Cosmetics such as theme and language are user-writable. Entitlements are not. Apps personalize from signed claims only. They also check entitlements on the server at every sensitive call (claims you can trust).
You can now follow a token from its birth to a trusted claim. You know how to rotate it, cancel it and tie it to a key. You know how to spread its death and check it at the door. A token shows who is asking. Authorization decides what they may touch. Start the next track with its first lesson.
Put it to work. Check your own tokens with our free security micro-tools at the tools shelf. Or explore our services. Or talk to our team when you are ready to design the real thing.