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
Scopes, consent & least privilege
A partner app wants to connect to Maya's account. What can it do after she agrees? That depends on the scopes the API offers and the consent screen Maya sees. Your goal: design scopes and consent so every app gets only the power it needs.
- A scope is a named permission, written like
bookings:read. - Small scopes fit least privilege. Big scopes and wildcards give away too much.
- Ask for the minimum first. Ask for more later.
- A scope limits the app. It does not name one record.
- For exact limits, such as "pay ₹500 to one payee", use RAR.
Scopes are the contract
A scope is a named permission. The app asks for it, and a user or admin grants it. Examples are bookings:read and payments:charge. A good name reads resource:action. Then anyone can see that profile:read is much smaller than admin:*.
Think of a society gate pass for a delivery person. It says: flat 4B, today, one time. It does not say: any flat, any day. A good scope is that narrow.
The hard part is granularity: how big each scope is. A big scope such as account is easy to request but gives away far too much. Small scopes fit least privilege, but there are more of them. Make each scope match one real job, and no wider.
| Scope | What it grants | Least-privilege verdict |
|---|---|---|
account | Everything about the account | Far too broad: avoid |
bookings:read | Read the user's bookings only | A clean resource:action fit |
payments:charge | Start a charge | Limited to one job |
admin:* | Every admin action | A wildcard: a red flag on any consent screen |
A scope limits the app, not the person. The app can do only what the scope allows and what Maya herself may do. A scope does not name one record. bookings:read does not say "only booking 1001". The API must still check each record (see the OWASP tour).
The consent screen lists: read your bookings, write your bookings, read your profile, read your contacts, and admin:*. Maya only wanted to see her trips. She taps Deny. The app lost its customer because it asked for too much.
Consent is a security tool
The consent screen is where authorization meets the person. It is the user's one chance to see what they hand over. A long list makes people deny, or click Allow without reading. You have seen this on your phone: a torch app asks to read your contacts. The fix is incremental consent. Ask for the minimum to start. Ask for more later, when a feature needs it. The app gets Maya in with bookings:read. It asks for payments:charge only at checkout.
Audience keeps a token in its place
A stolen token should not open every door. Audience ties a token to one API with the aud claim. The Payments API refuses a token made for the Bookings API, even if the scopes fit. Each API must check that it is the intended audience. Then one leaked token cannot roam your whole estate. See claims you can trust.
When scopes are too blunt: RAR
Some permissions do not fit a fixed scope. "Charge a card" is a scope. "Pay exactly ₹500 to this one account" is not. No list has a scope for every amount and payee. Rich Authorization Requests (RAR) solve this. The client sends a structured authorization_details object that describes the exact action and its limits. The user agrees to that one thing. This is least privilege taken to its end. RAR also supports human approval for agents and delegated access to other systems.
Go deeper: what a RAR request looks like
RAR is defined in RFC 9396, a Proposed Standard. The API decides which type values exist and which fields each one has. For a payment, the client could send this object inside authorization_details:
{"type":"payment_initiation","actions":["initiate"],"instructedAmount":{"currency":"INR","amount":"500.00"},"creditorAccount":{"upi_id":"kirana@examplebank"}}
To make a token fit one API, a client can also name the target with the resource parameter (RFC 8707). The token's aud claim then names that API.
🧪 Interactive lab — enable JavaScript to play with this one.
Rank the scopes a third-party app really asks for with Consent Check.