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
This is the last lesson of the program. Here is Architecture on one page: a cheat sheet, a question-to-call lookup and five scenarios. When you have revealed all five answers, go to the hub for the Final Exam and certificate.
Six ideas behind every identity design
| # | If you remember nothing else… |
|---|---|
| 1 | Keep tokens out of the browser. A BFF (backend-for-frontend) holds them on the server. The app gets only a hardened session cookie. XSS cannot read a token that was never in localStorage. |
| 2 | Across microservices, check once at the edge. Then pass trust on with care. Use token exchange (RFC 8693) to narrow power at each hop, and mTLS for service identity. Never forward the raw user token everywhere. |
| 3 | Keep tenants apart with a tenant claim from the token, a scoped check on every query, and tests. Isolation you do not test is isolation you do not have. |
| 4 | Use short access tokens, rotated refresh tokens and fast revocation. Lifetime is a dial between outage resilience and damage from theft. Set it on purpose. |
| 5 | Buy or adopt identity unless it is your product. Either way, join the parts with open standards (OIDC, SAML, SCIM) so you can move. |
| 6 | Plan for the IdP going down. Use graceful degradation (signed-in users keep working on saved keys), health-checked failover and a break-glass door for admins. |
Architecture question → the call
| The question… | …the call |
|---|---|
| Where do a browser app's tokens live? | In a BFF. The app gets only a hardened session cookie (where tokens live) |
| How does identity travel between services? | Check at the edge, exchange tokens per hop, mTLS inside (identity across microservices) |
| How do we keep tenants apart? | A tenant claim, scope every query to it, and isolation tests (multi-tenancy) |
| How long should tokens live? | Short access, rotated refresh, fast revoke (token lifetimes) |
| Build or buy identity? | Buy or adopt unless identity is your product. Use standards either way (build vs buy) |
| What if the IdP goes down? | Graceful degradation, failover and break-glass (when identity goes down) |
Pop quiz: five questions
Q1 · A team builds a single-page app. It keeps its access and refresh tokens in localStorage "for convenience". A month later, a third-party script brings in an XSS bug. What is the design fix?
Move the tokens out of the browser with a BFF. The server holds the tokens. The app gets only a hardened HttpOnly session cookie. XSS can still run script, but there is no token in localStorage to read or send away. The bug still needs fixing, because injected script can act through Maya's open tab (where tokens live and the BFF).
Q2 · An order service gets Maya's user token. It sends that same token to the billing service, the shipping service and a third-party tax API. Why is an architect uneasy?
Passing on the raw token gives every service, even a third party, all of Maya's power. One leak anywhere works everywhere. The fix is to check once at the edge. Then use token exchange (RFC 8693) to make a narrower token for each hop, with only what that service needs. Use mTLS to prove service identity (identity across microservices).
Q3 · In a shared-database product, one report runs SELECT * FROM invoices WHERE status = 'open'. A customer suddenly sees another tenant's invoices. What went wrong, and how do you prevent it?
The query has no tenant filter. In a shared pool, isolation is not automatic. Every query must use the tenant claim from the caller's token (for example AND tenant_id = :tenant). Build this into the structure, with a required scoping layer or row-level security, so no developer has to remember. Then add cross-tenant tests that prove one tenant can never read another's rows (multi-tenancy).
Q4 · To "reduce friction", an app issues access tokens that last three years. What did the architect give up?
The size of the damage if a token leaks. A stolen access token works until it expires, and it is hard to revoke. A three-year token is a three-year master key. The better design is short access tokens, rotated refresh tokens and fast revocation. Then a leak ends in minutes. Longer lives do help in an IdP outage. But turn that dial only a little. It is no reason for nearly permanent tokens (token lifetimes, IdP outages).
Q5 · At 9 a.m. the identity provider goes completely dark. Customers, staff and the on-call admin cannot sign in. Which design choices decide whether this is small or a disaster?
Three choices. Graceful degradation: signed-in users hold valid tokens that APIs check with saved keys, so they keep working until those tokens expire. Health-checked failover to a standby region brings new sign-ins back without a person. Break-glass lets the admin in to run the incident, without the IdP that is down. With none of the three, it is a total lockout. With all three, it is a status-page update (when identity goes down, break-glass).
That is Architecture, and the whole Identity & API Security program. You can now place tokens, carry identity across services, keep tenants apart, tune lifetimes, weigh build against buy, and keep going when identity fails. Here is what to do next:
- Prove it. The Final Exam covers every track in this program. Passing it earns your certificate.
- Stay sharp. Use the Daily drill, the Flow Explorer and Challenge mode.
- Try it for real. Practice on live systems in the Lab.
- Learn something new. The second program is Practical AI. Begin with AI from Zero.
When you are ready to design the real thing, talk to our team.
Warm up for the exam with the free security micro-tools on the tools shelf. Or see our services to find these designs built for real.