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 the whole protocol zoo in short. You get a cheat sheet, a "which flow do I use?" chooser and five scenarios to test yourself.
The ideas that decode any login
| # | If you remember nothing else… |
|---|---|
| 1 | A person logs in with authorization code + PKCE. The app gets a one-time code by redirect. It POSTs the code and the PKCE verifier to the token_endpoint. A thief has no verifier (RFC 7636). |
| 2 | SAML does the same job in signed XML. The IdP posts a signed assertion to the app's ACS address. Check the signature, and that it answers a request you sent. |
| 3 | No person anywhere? Use client credentials. A service logs in as itself with a secret or, better, a signed client assertion. |
| 4 | A gadget with no keyboard? Use the device flow. The person approves a short user code on a phone. The gadget polls until approved. |
| 5 | One service calls another API for a user? Use token exchange (RFC 8693). Trade the user's token for a narrower one that names the user and the caller. |
| 6 | A first arrival? JIT provisioning makes the account from verified claims at first login. Account linking joins a second sign-in method to an account. It needs fresh proof of the old account, never an unverified email alone. |
| 7 | An app finds a new login service through discovery (/.well-known/openid-configuration) plus published keys (JWKS, picked by kid). The issuer string must match exactly. |
| 8 | Lock down the ask, not only the answer. PAR (RFC 9126) pushes the request over the back channel. The browser carries only a request_uri. JAR (RFC 9101) signs it. FAPI 2.0 requires PAR, PKCE, exact redirect URIs, private-key client login and sender-constrained tokens. Use it for payments-grade flows only (PAR & FAPI). |
| 9 | Signing out is several jobs. The app ends its own session. RP-initiated logout (end_session_endpoint, id_token_hint, an exact post_logout_redirect_uri) ends the IdP session. Back-channel logout sends a signed logout token with a sid to each app. Front-channel uses hidden frames and can fail. Revoke refresh tokens (RFC 7009). A JWT access token lives until it expires unless the API checks a cut-off (signing out). |
You need… → use this flow
| You need… | …use this flow |
|---|---|
| A person logging in to a web or mobile app | Authorization code + PKCE (anatomy of a login) |
| No person anywhere: a backend calling an API | Client credentials (machine login) |
| A gadget with no keyboard (TV, command-line tool, IoT) to sign in | Device flow (device flow) |
| A person to approve a machine's action on their phone | CIBA: the user approves on another device (human-in-the-loop) |
| A service to call a downstream API for a user | Token exchange (token exchange) |
| An older company app that speaks only XML | SAML (SAML) |
| To sign a user out of everything at once | RP-initiated logout, back-channel logout and revoking the refresh token (signing out across apps) |
| A high-stakes flow such as payments or open banking | PAR + PKCE + exact redirect URIs, or the whole FAPI 2.0 profile (PAR & FAPI) |
Pop quiz — five questions
Q1 · Maya logs in, and the IdP redirects to her app with ?code=abc123. An attacker sees the redirect and tries to redeem the code at the token_endpoint first. Why does the attempt fail?
PKCE (RFC 7636). At the start, Maya's app made a secret verifier and sent only its hash (the challenge). To redeem the code, you must show the original verifier. It never left the app. The token endpoint hashes it, compares it to the challenge and refuses a mismatch with invalid_grant (anatomy of a login).
Q2 · Maya's app gets a correctly signed SAML assertion that says she is logged in. But the app never sent a login request. Should it log her in?
No. A valid signature proves only who wrote the assertion. It does not prove that you asked for it. An attacker may be replaying or injecting an assertion. The app must match the response to an InResponseTo request it really sent. It must also check the audience and the times, and refuse a reuse (SAML).
Q3 · A nightly batch job calls the payments API. A developer hard-codes the client secret in the repo, and it lands in the git history. Which flow is this, and what is the right fix?
It is the client credentials flow: a machine logs in as itself, with no user. The leaked secret is now a standing key to the payments API. Replace it right away. Then move to a signed client assertion (RFC 7523) or a workload identity, so no shared secret exists to leak. Keep credentials in a secrets manager. Limit the token to what the job needs (machine login).
Q4 · Priya gets a text: "Your help desk is finishing setup. Go to the activation page and enter code WXYZ-1234 to approve." She is busy and almost does it. What attack is this, and which flow is abused?
It is device-code phishing, which abuses the device flow. The attacker started a device login on their own gadget and got a user code. Now they trick Priya into approving their session on her account. Defenses: never approve a code you did not start. Show the requesting app on the approval screen. Keep codes short-lived and rate-limited (device flow).
Q5 · A new user signs in with a fresh social login. Its only identifier is an email address that the app has seen before. The app wants to merge the two by matching the email. Why is that dangerous?
Linking by an unverified email invites account takeover. Someone can claim an email at a careless provider and be merged into another person's account. Safe account linking needs fresh proof: the user must log in to the existing account (or verify the email with a new challenge) first. JIT provisioning should create accounts only from verified claims (JIT provisioning and account linking).
You can now read a login off the wire. You can pick the right flow for people, machines and gadgets. Next up is API security. Every token and flow you just learned ends at an API. So now you secure that front door. You will study the sign-in menu, certificates and TLS, signed requests and webhooks, CORS, and rate limits. Start the API security track.
Put it to the test. Browse our free security tools on the tools shelf, or explore our services. Talk to our team when you are ready to design the real thing.