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
Start here: who can do what
Priya has logged in, so the app knows who she is. Now it must check what she is allowed to do. That check is authorization. Your goal: learn how to decide who can do what in an app.
You already live with this
Many things around you check who can do what. You just do not call it authorization. Here are five.
🪪 An office ID card
Your card opens the main gate, the canteen and your own floor. It does not open the server room. Your job decides which doors open. This is a role.
📁 The family Google Drive folder
Amma shares the "House papers" folder with her children. Anyone inside the folder can open every file in it. A link between people and things decides. This is a relationship.
🔐 A bank locker with two keys
The bank staff has one key. You have the other. The locker opens only with both, and only in bank hours. Several conditions must be true together. This is a rule.
💬 A WhatsApp group admin
The admin can add and remove people. A member can only send messages. The admin of your family group has no power in the office group. Power stops at the group edge.
🚆 A railway reservation chart
The TTE finds your name next to a seat on this train. A valid ticket for another train, or for another person, does not help. The check is about this one seat.
The next lessons give these pictures their real names. The role picture is RBAC. The relationship picture is ReBAC. The rule picture is ABAC and policy as code. The group edge is multi-tenancy. The seat check is the number-one API risk.
Why this track
Logging in is only the first step. If the app lets anyone read anyone's data, the login did not help. Authorization runs at your APIs. It builds on zero trust and leads to fine-grained access for AI. The API security track goes deeper later.
The path
- RBAC, ABAC & ReBAC — three ways to answer "who can do what."
- Permissions as a graph — model sharing with relationships.
- Policy as code — move rules out of the app code.
- Multi-tenancy — every check asks "which tenant?"
- Scopes & consent — give each grant the least power it needs.
- API keys vs OAuth — pick the right credential for the caller.
- The API gateway — check every call at the front door.
- OWASP API Top 10 — a tour of how APIs break.
- The big picture — the whole track in one story.
- Cheat sheet & pop quiz — the track in short, then five scenarios.
Take one lesson at a time. Most have a hands-on lab.
You will pick the right access model. You will write rules as policy. You will give each credential only the power it needs, called least privilege. You will check calls at an API gateway and spot the OWASP API Top 10 risks.
Logging in got Maya through the door. Now see what happens next. Start with RBAC, ABAC & ReBAC.