🛡️ Authorization - RBAC, ABAC, & Policies

Don’t sprinkle if (user.isAdmin) checks throughout your business logic. Authorization should be a decoupled layer or a dedicated service. A Programmer designs for the Principle of Least Privilege, ensuring users only have access to the specific data they need to perform their job.

👥 1. RBAC (Role-Based Access Control)

The most common model. Permissions are grouped into Roles, and Roles are assigned to Users.

Structure: User ⮕ Role ⮕ Permission.
Example: A “Editor” role has the update_post and delete_post permissions.
Pros: Very easy to understand and audit. Excellent for 80% of application needs.
Cons: Can lead to “Role Explosion” (e.g., creating Manager_Region_A, Manager_Region_B) when permissions need to be more granular.

🧪 2. ABAC (Attribute-Based Access Control)

A more dynamic model that uses Attributes (properties) of the user, the resource, and the environment to make a decision.

Structure: IF (Subject.Attribute AND Resource.Attribute AND Environment.Attribute) THEN Allow.
Example: “Allow Engineers to Access Servers only if Server.Project == User.Project and Time is during working hours.”
Pros: Extremely flexible; avoids role explosion.
Cons: High complexity; can be difficult to reason about and can impact performance if rules are too complex.

📜 3. Policy-Based Access Control (PBAC / ReGo)

Taking authorization out of the code and into a configuration or policy engine.

Opa (Open Policy Agent): A popular industry standard. You write policies in a language called Rego.
How it works: Your API sends a “query” to the policy engine (e.g., “Can User X do Action Y on Resource Z?”), and the engine returns a simple true/false.
Programmer’s Move: This allows security teams to update permissions across multiple microservices without redeploying code.

🏛️ 4. ReBAC (Relationship-Based Access Control)

Popularized by Google’s Zanzibar paper. It defines access based on relationships between entities.

Logic: “User A can edit Document B because User A is a member of Folder C, and Folder C contains Document B.”
Best for: Complex hierarchical structures (like Google Drive, Notion, or Slack).

🛠️ Implementation Patterns

Centralized vs. Decentralized

Centralized: One “Authorization Service” handles all checks. Great for consistency, but creates a single point of failure and adds network latency.
Decentralized: Each microservice handles its own authorization. Faster, but harder to ensure uniform security policies across the company.

The “Data Filtering” Problem

Authorization isn’t just about Allow/Deny. It’s often about filtering what comes back from the database.

Junior approach: Fetch all records, then loop through them in the API and remove the ones the user shouldn’t see. (Slow and memory-intensive).
Senior approach: Inject authorization constraints into the Database Query itself (e.g., SELECT * FROM orders WHERE user_id = ?).

Scopes vs. Permissions

Scopes (OAuth2): High-level “buckets” of access (e.g., read:profile, write:orders). These are usually what the application is allowed to do.
Permissions: Granular internal checks (e.g., can_refund_over_500). These are what the user is allowed to do.

💡 Note: Always audit your authorization. Implement Access Logging so you can answer the question: “Who accessed this sensitive record and when?” In highly regulated industries, being able to prove that your authorization works is just as important as the authorization itself.