Authorization is the process of determining whether an authenticated user has permission to access a specific resource or perform a specific action. It answers the question: "What are you allowed to do?"

Think of a Hospital:

1. You have been Authenticated (You have an ID badge that says you are a Doctor).
2. You try to enter the Surgery Room. The door opens. (You are Authorized).
3. You try to enter the Accounting Office to see everyone's salary. The door stays locked. (You are Not Authorized).
4. Even though you are a valid person in the hospital, your "Role" doesn't give you permission for every room.

---

Access Control Models

1. RBAC (Role-Based Access Control): Permissions are assigned to "Roles" (e.g., Admin, Moderator, User). Users are then assigned to those roles. (Most common).
2. ABAC (Attribute-Based Access Control): Permissions are based on attributes (e.g., "Can view file IF Dept is 'Sales' AND Time is '9am-5pm'"). (More flexible but complex).
3. ACL (Access Control Lists): A specific list attached to a resource (e.g., "File A can be read by User 1 and User 2").

Where to check Authorization?

• At the Gateway: Good for blocking entire paths (e.g., only Admins can hit /admin/*).
• In the Service: Mandatory for complex rules (e.g., "A user can only edit their own posts").

---

Principle of Least Privilege

Always mention this! Your system should only give a user the minimum permissions they need to do their job. Don't make every employee an "Admin" just because it's easier to code.

Confused Deputy Problem

This is a security vulnerability where a service with high permissions is tricked by a user with low permissions into performing an action on their behalf.

Key Implementation Detail

In a JWT, you can store the user's roles or permissions in the "Claims" section. This allows the backend to check authorization without a database call for every request. Warning: If a user's role changes, their old JWT will still have the old role until it expires! 🛡️