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 track in short. You get a cheat sheet, a "which tool for which job?" table, and five scenarios to prove it stuck.
The ideas that decide every request
| # | If you remember nothing else… |
|---|---|
| 1 | Pick the model to fit the question. RBAC for roles ("is Priya an admin?"). ABAC for attributes and context. ReBAC for links ("can Maya open this record?"). Most systems mix them (access models). |
| 2 | Model permissions as a graph of relationship tuples. Answer with Check(). Ownership and sharing become links, not long if chains (the graph). |
| 3 | Write authorization as policy as code. A PDP decides and a PEP enforces. Keep the rules in version control and test them (policy as code). |
| 4 | In a shared product, every check asks which tenant. Take the tenant from the verified token, never from the URL or body. Filter every query, add row-level security, and test for leaks (tenant isolation). |
| 5 | Scopes limit what a token may do. Consent is the user agreeing to that grant. Least privilege means asking for the narrowest scope that works (scopes and consent). |
| 6 | For machines, prefer short-lived scoped tokens (client credentials) to API keys that never expire. Better still, drop the shared secret with private_key_jwt, mTLS or workload identity (keys vs tokens). |
| 7 | Make the gateway your PEP. Check signature, expiry, audience and issuer locally. Enforce scopes and rate limits. Validate the schema. Use mTLS behind it too, so there is no soft center (the gateway). |
| 8 | Most breaches are a missing authorization check, not broken crypto. BOLA tops the OWASP API Top 10. Always ask "does this caller own this object?" (the OWASP tour). |
Which tool for which job?
| Model or tool | Reach for it when… |
|---|---|
| RBAC | Access follows the job. A few steady roles cover it. |
| ABAC | The answer depends on facts such as department, time, device or risk. |
| ReBAC | Permission depends on a link to one object (owner, editor, member). |
| Policy engine (OPA, Cedar) | You want rules kept apart from the app, tested, and shared across services. |
| AuthZEN | You want one standard API between your PEP and any PDP. |
| Scopes | You want to limit a token or app in broad steps, API-wide. |
| RAR (RFC 9396) | You need the exact detail of one action: the amount and the target. |
| API key | The data is public and read-only, or you only need a label for rate limits. |
| Client credentials | A machine calls a machine and needs expiry, a name in the logs, and central cancel. |
| Tenant from the token + filter + RLS | Many customers share one system and none may see another's data. |
| Gateway rate limit | You want fairness, slower guessing, and a stop for a runaway client or agent. |
Pop quiz: five questions
Q1 · Maya reads her booking at GET /bookings/1001. Then she changes the URL to /bookings/1002 and sees Sam's booking. The token is valid and the reply is 200 OK both times. Which OWASP API risk is this? Which check was missing?
API1 · Broken Object Level Authorization (BOLA), the top API risk. The token was valid, but the server never ran an object-level check. Nobody asked, "does this caller own object 1002?" The fix is a per-object check on every request. A ReBAC graph answers it well: is Maya the owner of 1002? No, so return 403 (OWASP tour; the graph).
Q2 · Can Priya open a document that Sam shared with her team? Access follows ownership and sharing, not job title. Which model fits? Why not plain RBAC?
ReBAC (relationship-based). The permission depends on a link to one object: owner, editor, team member. RBAC's broad roles cannot say this without thousands of roles. You store relationship tuples and answer with Check(). RBAC still fits steady, job-shaped access, so mix both (access models; the graph).
Q3 · Your team wants the same authorization rules in six services. The rules must sit in version control and be tested before release. They must not be rewritten in each codebase. Which pattern gives this? Which two roles does it use?
Policy as code (for example OPA with Rego). The rules are versioned, testable files. A central PDP (policy decision point) evaluates them. A PEP (policy enforcement point), often the API gateway, asks and applies the answer. Decisions stay consistent and auditable in every service (policy as code; the gateway).
Q4 · A third-party app wants to connect to Maya's account. It asks for scopes to read and delete everything, but it only needs to read her upcoming bookings. Which principle is broken? Who decides?
Least privilege. The app should ask for the narrowest scope that does the job (bookings:read), not a sweeping read-and-delete. Maya decides on the consent screen. It must show what she grants, so she can refuse a greedy request. An over-scoped grant is a standing risk if that app is ever breached (scopes and consent).
Q5 · Bot A calls the billing API every night with a static API key. Someone pasted it into a CI setting two years ago. It has leaked to a public repo, and nobody noticed. What should Bot A carry instead? Why is the leak worse with a key?
A short-lived, scoped access token from the OAuth client credentials grant. A static key never expires and names nobody. Changing it is a fire drill. So a leaked copy works until a human remembers to change it. A token expires in minutes, so the leak heals itself. It carries a client_id, so logs name the caller, and you can cancel it centrally. Better still, private_key_jwt, mTLS or workload identity removes the shared secret (keys vs tokens; non-human identities).
You have finished Authorization. You can pick the right model, draw permissions as a graph, write policy as code, scope grants with consent, give machines credentials that expire, and check every call at a gateway. You also know never to skip the object-level check. Next, watch these rules travel across the wire in Protocols & Federation.
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.