$ open blueprint
Authorization is one of those architectural concerns that often looks simple at the beginning and becomes increasingly difficult as a SaaS platform grows. In a system like BizNex OS, access decisions are not limited to deciding whether a user is an admin or a regular employee. The platform must continuously determine which user can perform which action, on which resource, under which organization, and under which business rules.
Executive Summary
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
Many systems implement authentication correctly.
Far fewer implement authorization correctly.
In most real-world security incidents, attackers are not bypassing authentication.
They are abusing excessive permissions.
A user sees records they should not see.
An employee accesses another department's data.
A manager edits financial records they should only view.
An API exposes resources outside tenant boundaries.
These are authorization failures.
For founders, authorization protects business data.
For senior engineers, authorization becomes one of the most important architectural concerns in the entire platform.
Role-Based Access Control (RBAC) remains one of the most widely adopted authorization models because it maps permissions to roles rather than individual users. Hierarchical RBAC allows roles to inherit permissions, reducing duplication and simplifying management.
The Business Problem
Imagine building BizNex OS.
Customers store:
- Employees
- Products
- Orders
- Financial Records
- Payroll
- Reports
Every user cannot access everything.
The platform needs to answer:
Can this user perform this action
on this resource
inside this organization?
Examples:
Can Accountant view invoices?
Can Manager approve payments?
Can Employee edit payroll?
Can Warehouse Staff update inventory?
Authorization exists to answer these questions consistently.
Why Founders Should Care
Authorization directly impacts:
- Security
- Compliance
- Customer trust
- Enterprise adoption
Enterprise customers frequently ask:
Can managers restrict employee access?
Can finance teams access payroll?
Can branch managers access only their branch?
Can we audit permission changes?
Without strong authorization:
- Enterprise deals become difficult
- Compliance becomes harder
- Security incidents become more likely
Why Senior Engineers Should Care
Authorization affects:
- APIs
- Databases
- Background jobs
- Admin panels
- Reporting systems
- Audit logging
Poor authorization creates technical debt that spreads across the platform.
Retrofitting permissions later is significantly more expensive than designing them early.
The Authorization Pyramid
Ownership
│
▼
Object-Level Rules
│
▼
Policies
│
▼
Permissions
│
▼
Roles
│
▼
User
Every access decision should move upward through this hierarchy.
RBAC Fundamentals
RBAC is built around three concepts:
Users
Roles
Permissions
Permissions are assigned to roles.
Users receive permissions through roles.
Users should rarely receive permissions directly.
Core RBAC Model
User
│
▼
Role
│
▼
Permissions
│
▼
Resources
Example:
Role: Accountant
Permissions:
invoice.view
invoice.create
invoice.update
payment.view
Assigning a user to the Accountant role automatically grants those permissions.
The Biggest Authorization Mistake
Many teams build:
Admin
User
And stop there.
This quickly becomes impossible to manage.
As products grow:
Admin
Manager
Accountant
Sales Manager
Sales Agent
Warehouse Staff
Procurement Officer
Branch Manager
Auditor
Owner
Authorization requires granular permissions.
Designing Permissions First
Instead of creating roles first:
Create permissions first.
Example:
invoice.view
invoice.create
invoice.update
invoice.delete
payment.view
payment.approve
inventory.adjust
report.export
Then combine permissions into roles.
This approach scales far better.
High-Level Authorization Architecture
Request
│
▼
Authentication
│
▼
Tenant Check
│
▼
Role Lookup
│
▼
Permission Evaluation
│
▼
Object-Level Rules
│
▼
Allow/Deny
Hierarchical Roles
One of RBAC's most powerful features is permission inheritance.
A higher role inherits permissions from lower roles.
Example:
Employee
│
▼
Manager
│
▼
Director
│
▼
Owner
Inheritance:
Owner
├─ Director Permissions
├─ Manager Permissions
└─ Employee Permissions
Benefits:
- Less duplication
- Easier management
- Consistent access control
Multi-Tenant RBAC
Traditional RBAC is not enough for SaaS.
Example:
User A
Role: Manager
Organization A
Should NOT automatically become:
Manager
inside Organization B
Roles must be scoped to organizations.
Example:
User
│
▼
Membership
│
▼
Organization
│
▼
Role
This pattern is common in SaaS systems.
Real Database Design
users
organizations
memberships
roles
permissions
role_permissions
Relationship:
User
│
Membership
│
Organization
│
Role
│
Permissions
Multi-Role Support
Real users often need multiple roles.
Example:
Manager
Accountant
Combined permissions:
invoice.view
invoice.create
payment.approve
report.export
Modern RBAC implementations often aggregate permissions from multiple assigned roles.
Object-Level Authorization
RBAC alone is not enough.
Example:
Can edit invoice
Question:
Which invoice?
Object-level authorization adds resource ownership and tenant checks.
Example:
invoice.organization_id == request.organization.id
This prevents cross-tenant data access.
Ownership-Based Authorization
Example:
Can Edit Blog Post
Rule:
Only Creator Can Edit
This is not traditional RBAC.
It is ownership-based authorization.
This is often considered a relationship-based access control pattern because the decision depends on the relationship between the user and the resource.
Fine-Grained Policies
Enterprise systems often need rules such as:
Can approve invoices
under $10,000
Or:
Can access reports
during business hours
RBAC alone struggles with these scenarios.
Policy engines become useful.
Example:
Role
+
Resource Attributes
+
Context
RBAC vs ABAC
RBAC
Role → Permission
Example:
Accountant
Can:
View Invoices
ABAC
User Attributes
+
Resource Attributes
+
Context
Example:
Department = Finance
AND
Region = Dhaka
AND
Working Hours
Then Allow Access.
ABAC provides more flexibility but increases complexity.
Permission Evaluation Flow
Request
│
▼
User Authenticated?
│
▼
Tenant Valid?
│
▼
Role Exists?
│
▼
Permission Exists?
│
▼
Object Ownership?
│
▼
Allow / Deny
Separation of Duties
A critical enterprise security principle.
Example:
Bad:
Create Vendor
Approve Vendor Payment
Same User
Risk:
Fraud
Constrained RBAC introduces separation-of-duty rules to prevent these conflicts.
Good:
Procurement Officer
Creates Vendor
Finance Manager
Approves Payment
Authorization in APIs
Never trust:
{
"role": "admin"
}
from the client.
Always evaluate authorization server-side.
Example:
request.user.has_permission(
"invoice.approve"
)
The client can request an action, but the server must decide whether that action is allowed.
Authorization in Background Jobs
Background jobs must carry enough security context to preserve authorization boundaries:
organization_id
actor_id
permission_context
Without tenant context:
Data leakage becomes possible.
Audit Logging
Every authorization-sensitive action should be logged.
Example:
Who
Did What
To Which Resource
Inside Which Organization
At What Time
Audit logs become essential for:
- Compliance
- Security investigations
- Enterprise customers
Common Authorization Mistakes
Direct User Permissions Everywhere
Bad:
User → Permission
Thousands of combinations.
Difficult to manage.
Tenant-Unaware Roles
Bad:
User Is Manager
Good:
User Is Manager
Inside Organization A
Authorization Only in UI
Bad:
Hide Button
Users can still call APIs.
Authorization must be enforced server-side.
Role Explosion
Bad:
Manager
ManagerPlus
ManagerRegional
ManagerRegionalSenior
Permission-first design helps prevent this problem.
Evolution Path
Simple Roles
│
▼
Permissions
│
▼
Hierarchical RBAC
│
▼
Multi-Tenant RBAC
│
▼
Object-Level Authorization
│
▼
Policy Engine
│
▼
RBAC + ABAC Hybrid
Real-World Examples
AWS IAM
AWS IAM supports policy-based authorization and can express fine-grained access decisions using identities, resources, actions, and conditions.
Kubernetes
Kubernetes uses RBAC extensively through Role, ClusterRole, RoleBinding, and ClusterRoleBinding to control access to cluster resources.
Enterprise ERP Systems
Commonly use:
RBAC
+
Organization Scoping
+
Approval Workflows
for finance, inventory, procurement, and payroll.
What I Would Build Today
For a modern SaaS platform:
JWT Authentication
Organization Membership
RBAC
Permission-Based Access
Hierarchical Roles
Object-Level Authorization
Audit Logs
Tenant-Aware Policies
I would not start with:
Hundreds of Roles
Custom Rules Everywhere
Direct User Permissions
Start simple.
Design for evolution.
Key Takeaways
Authorization is not a feature.
It is a platform capability.
Authentication proves identity.
Authorization governs power.
The most scalable systems assign permissions to roles, scope roles to organizations, validate ownership of resources, enforce authorization on the server, and audit every sensitive action.
A strong authorization architecture protects both the business and the customers who trust it.
