Interactive Explainer

🎯Key Takeaways

Authorization answers "what can you do?" after authentication.

RBAC uses roles; ABAC uses attributes (user, resource, context).

Least privilege means granting only the minimum permissions needed.

What is authorization?

Who can do what-after the app knows who you are.

~3 min read

Be the first to complete!

What you'll learn

Authorization answers "what can you do?" after authentication.
RBAC uses roles; ABAC uses attributes (user, resource, context).
Least privilege means granting only the minimum permissions needed.

Lesson outline

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.

Editor → read, write, edit, delete posts

Policies

Structured rules with conditions, wildcards, and logic. Easier to manage at scale.

allow read if user.role is Viewer

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").

RBAC = by role (Admin, Editor, Viewer)

ABAC = by attributes (user, resource, time)

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: simple admin vs viewerUse ABAC: rule depends on resource or context

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.

1000 users → 1000 ACL updates

Roles / policies

Change the role once; everyone with that role gets the update. Scales better.

Viewer → read1 change, all viewers updated

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.

How this might come up in interviews

Backend and cloud interviews: expect to design or explain access control (roles, policies, IAM) for an app or cloud account.

Common questions:

What is the difference between RBAC and ABAC?
How would you implement least privilege in IAM?
When would you use ACLs vs roles?

Key takeaways

Authorization answers "what can you do?" after authentication.
RBAC uses roles; ABAC uses attributes (user, resource, context).
Least privilege means granting only the minimum permissions needed.

Before you move on: can you answer these?

When would you choose ABAC over RBAC?

When the rule depends on the resource or context (e.g. "only the author can edit", "only during business hours") rather than a fixed role.

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

What is security?

Practice with these scenarios

Apply this concept in hands-on scenarios.

Test yourself: 1 challenge

Apply this concept with scenario-based Q&A.

Design GCP IAM hierarchy for multi-team organization

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning

What is security?

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord

In-app Q&A

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?"

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.

Editor → read, write, edit, delete posts

Policies

Structured rules with conditions, wildcards, and logic. Easier to manage at scale.

allow read if user.role is Viewer

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").

RBAC = by role (Admin, Editor, Viewer)

ABAC = by attributes (user, resource, time)

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: simple admin vs viewerUse ABAC: rule depends on resource or context

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.

1000 users → 1000 ACL updates

Roles / policies

Change the role once; everyone with that role gets the update. Scales better.

Viewer → read1 change, all viewers updated

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.

What is authorization?

What is authorization?

Authentication vs. authorization

Authentication — Passport

Authorization — Boarding pass

How it works in applications

Principle of Least Privilege

Roles, policies, and access control

Roles

Policies

Attribute-based access control (ABAC)

RBAC (Role-Based)

ABAC (Attribute-Based)

Access control lists (ACLs) and permissions

ACLs

Roles / policies

Authorization in practice

Real-world scenario: document sharing

Discussion

In-app Q&A

What is authorization?

What is authorization?

Authentication vs. authorization

Authentication — Passport

Authorization — Boarding pass

How it works in applications

Principle of Least Privilege

Roles, policies, and access control

Roles

Policies

Attribute-based access control (ABAC)

RBAC (Role-Based)

ABAC (Attribute-Based)

Access control lists (ACLs) and permissions

ACLs

Roles / policies

Authorization in practice

Real-world scenario: document sharing

Discussion

In-app Q&A