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 a map from problem to defense. Last, five questions to check what stuck.
One idea per lesson
| # | If you remember nothing else… |
|---|---|
| 1 | A passkey's private key is never sent to the site. It is tied to the site's domain. A fake page cannot trigger it (passkeys). |
| 2 | Factors form a strength ladder: passkey, then push, then SMS. Never make lost-factor recovery depend on the factor that may be lost (MFA). |
| 3 | Recovery is a door too. Best: a second passkey. Next: single-use recovery codes, shown once and stored as hashes. Never text or email alone. At the help desk: call back a number on file, a second person approves, wait, notify, log (account recovery). |
| 4 | Score every login and challenge only the risky ones. Look at new device, impossible travel and bad IP. Real users pass quietly (adaptive MFA). |
| 5 | Being logged in is not the same as having just proven it. Tie risky actions to amr, acr and auth_time. The API is the gate. Judge freshness by auth_time (step-up). |
| 6 | A CAPTCHA needs a screen. So a back-channel login must hand off to the hosted page (bot detection). |
| 7 | Check passwords against leak lists with k-anonymity. Only 5 hash characters leave your server. Block, do not warn (breached passwords). |
| 8 | Let customers bring their own IdP. The email domain is the map. Verify domain ownership first (enterprise SSO). |
| 9 | One login makes three sessions on three clocks: IdP, app and tokens. Protect the cookie with HttpOnly, Secure, SameSite and a sliding expiry. Clearing a cookie is not logout. Back-channel logout ends the whole SSO estate (sessions). |
| 10 | Carry a sign-in from native to web with a single-use ticket that lasts about 60 seconds. The refresh token never reaches the browser (native-to-web SSO). |
| 11 | A magic link is a single-use, short-lived token sent by email. It is only as safe as that mailbox. Use passkeys when the account is worth protecting (magic links). |
| 12 | Authentication shows you hold the credential. Identity proofing shows you are the real person. Match the assurance level (IAL) to the risk. Delete raw ID scans once the law allows (identity verification). |
Problem to defense: a quick map
| When you see… | …reach for |
|---|---|
| Users are phished even with MFA on | Origin-bound passkeys. The key will not sign for a fake domain. Teach users to spot fake messages too. |
| Credential stuffing with leaked passwords | Breached-password checks, bot detection and limits on repeated tries |
| Every login asks for a second factor and users complain | Adaptive MFA: challenge only low-confidence attempts |
| A high-value action arrives on an old token, or one made from a refresh token | Step-up: answer 401 insufficient_user_authentication and ask for fresh MFA |
| A user dropped the phone and is locked out | Recovery that does not depend on the lost factor: a second passkey or saved recovery codes |
| A caller asks the help desk to reset an account | Help-desk rules: call back a number on file, a second person approves, wait, then notify |
| A business customer will not manage another password | Enterprise SSO over SAML or OIDC, with home-realm discovery by email domain |
| An attacker claims another company's domain to steal SSO routing | Verify domain ownership (a DNS TXT record) before you map a domain |
| A web page opened from the native app asks for a second login | Native-to-web SSO: a single-use ticket, with the refresh token kept off the browser |
| A user signed out, but still has access | Back-channel logout and token revocation, not only a cleared cookie |
Pop quiz: five questions
Q1 · Maya clicks an email link to a page that looks exactly like your login. Her device will not offer her passkey. Why not?
A passkey is tied to the real site's domain (the relying-party ID). The browser offers it only on that exact domain. A fake page cannot trigger it (the passkeys lesson).
Q2 · Priya types priya@bigcorp.com. With no menu, she lands on Bigcorp's own login. What sent her there? What must you check before you trust that map?
Home-realm discovery maps the email domain to the right company connection. The domain is the part after the @. Before you trust it, verify domain ownership with a DNS TXT record (the enterprise SSO lesson).
Q3 · Maya's app sends a token with amr=mfa to approve a ₹25,000 payment. The API refuses it. The token is real. Why was it refused? What fixes it?
The MFA happened long ago, so auth_time is old. A token made from a refresh token does not show that a person is at the screen now. The API answers 401 insufficient_user_authentication and names the acr_values and max_age it needs. The app asks for fresh MFA and retries the same call (the step-up lesson).
Q4 · Zara sees a credential-stuffing wave hit a login that uses a back-channel password grant. The app has no screen that the IdP controls. Why do the bots not get in?
The token call returns requires_verification. The app sends the user to the hosted login page. There a CAPTCHA is shown. Bots with no browser cannot solve it. Breached-password checks also block reused leaked passwords (the bot-detection lesson).
Q5 · Maya is signed in on the native app. It opens a web page, and she is already signed in there too. What carried the sign-in across? What three things keep it safe?
A single-use session-transfer ticket, made from the refresh token. It is single-use and lasts about 60 seconds. The refresh token never reaches the browser. And the redemption is tied to the user who started it (the native-to-web SSO lesson).
You now know how modern authentication proves who is there: passkeys, adaptive MFA, step-up, SSO and the bridges between apps. Next, follow the tokens that these logins hand out. Start the Token Security track with its first lesson.
Put it to work. Grade a real login with our free security micro-tools. Or explore our services. Or talk to our team when you are ready to design the real thing.