What is authorization?
Who can do what-after the app knows who you are.
Authentication vs. authorization
Authentication = "Who are you?" (login, token, MFA). Authorization = "What are you allowed to do?" (view, edit, delete).
Auth happens once (or when the token is refreshed). Authorization happens on every request that touches protected data: "Can this user do this action on this resource?"
Building analogy: authentication gets you in the door; authorization says which rooms you can enter.
Authentication gets you through the door; authorization decides which rooms you can enter.
Authentication — Passport
Proves who you are
Happens first, before any access decisions.
- Login form with email and password
- "Sign in with Google" (OAuth sign-in)
- MFA code on your phone
Authorization — Boarding pass
Decides what you can do
Checked on every important action.
- Can view your own profile but not others
- Admins can manage users; viewers cannot
- Only the owner can delete their own resource
How it works in applications
Before any sensitive action (delete file, edit record, call API), the app asks: "Does this user have permission?"
It uses roles (e.g. admin vs viewer), attributes (e.g. department = Sales), or allow/deny rules. Least privilege = give only the minimum access needed. Need read only? Don’t grant write.
Same idea everywhere: AWS IAM, Azure RBAC, Kubernetes RBAC, app-level permissions.
On every sensitive action the app asks: “Does this user have permission?”
Request
Delete file, edit record, call API
Permission check
Does this user have permission?
Allow
Access granted
Deny
403 Forbidden
Principle of Least Privilege
Grant only the minimum access needed. If someone only needs to read data, don't give them write access. This limits the damage if their account is compromised.
Roles, policies, and access control
Role = a bundle of permissions. You assign "Editor" instead of "read + write + edit + delete" one by one. Change the role once; everyone with that role gets the update.
Policy = a rule in code. Example: "allow read if user.role is Viewer". Policy languages support conditions, wildcards, and "if user.department = resource.department".
Auth gives you who; roles and policies say what they can do. AWS IAM, Azure RBAC, GCP IAM all work this way.
Roles
Group permissions: assign “Editor” instead of dozens of individual rights.
Policies
Structured rules with conditions, wildcards, and logic. Easier to manage at scale.
Real systems combine identity from authentication with these rules to allow or deny each request. Same ideas in AWS IAM, Azure RBAC, Kubernetes RBAC.
Attribute-based access control (ABAC)
RBAC = decide by role (e.g. "Editor"). ABAC = decide by attributes: user (department, role), resource (owner, status), environment (time, IP).
Example ABAC rule: "Allow edit if user.department = resource.department AND time is 9–5 AND resource.isFinal is false." More flexible than RBAC, more complex to manage.
Use RBAC for simple "admin vs viewer". Use ABAC when the rule depends on the resource or context (e.g. "only author can edit", "only during business hours").
Example ABAC rule
Allow edit if user.department = resource.department AND time is 9–5 AND resource.isFinal is falseMore flexible than RBAC, more complex to manage.
RBAC (Role-Based)
Assign users to roles (Admin, Editor, Viewer). Decision = role only.
- Easy to understand
- Fast to implement
- Can lead to "role explosion"
- Limited flexibility
ABAC (Attribute-Based)
Decision = user + resource + environment (e.g. time, IP).
- Highly flexible
- Supports complex rules
- Scales better
- More complex to set up
Access control lists (ACLs) and permissions
ACL = permissions on the resource. Each file or object has a list: "Alice: read/write, Bob: read". Common in file systems (Linux chmod) and object storage.
ACLs are simple but don’t scale: change 1000 users = update 1000 ACLs. Roles scale: change the role once, everyone with that role updates.
Many systems use both: roles for broad access, ACLs for per-resource overrides (e.g. "this folder: only these three users").
ACLs
Permissions attached to each resource. Simple, but changing 1000 users can mean 1000 updates.
Roles / policies
Change the role once; everyone with that role gets the update. Scales better.
Many systems use both: roles for broad patterns, ACLs for resource-specific exceptions.
Authorization in practice
Authorization is checked in many places: your app, API gateway, database, cloud service. Defense in depth = check at each layer.
Cloud managed auth (AWS IAM, Azure AD, GCP IAM) handles users, roles, and policies. Your app calls them instead of building its own. You configure who can do what; they enforce it.
Authorization happens at multiple layers — defense in depth.
Application
Checks permissions before allowing access
API gateway
Checks permissions before allowing access
Database
Checks permissions before allowing access
Cloud services
Checks permissions before allowing access
Your app, API gateway, database, and cloud services can each enforce authorization. Same ideas in AWS IAM, Azure RBAC, Google Cloud IAM.
Real-world scenario: document sharing
Expert scenarioRule: "Employee can edit this document only if they are the author and the document is not marked Final."
RBAC alone fails: the rule depends on this document (author, isFinal), not just "Editor" role. You need ABAC or a policy engine (e.g. Open Policy Agent) that can check user + resource + flags at runtime.
Same pattern everywhere: approvals, ownership, time windows, status flags → fine-grained "who can do what on which thing".
Decision: RBAC is not enough — you need ABAC or a policy engine.
Edit only if you are the author and document is not Final.
Check user + resource attributes (author, isFinal) at runtime.
e.g. Open Policy Agent — fine-grained rules, ownership, time windows, status flags.
Sign in to track progress on your dashboard.
Ready to see how this works in the cloud?
Switch to Career Paths on the Academy page for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based paths