Authorization
aw-thur-ih-ZAY-shun
The process of determining what actions or resources an authenticated user is allowed to access.
Authorization answers the question: what are you allowed to do? After authentication confirms your identity, authorization checks your permissions. Can you view this document? Can you delete this project? Can you invite new team members? Can you access the billing page? These decisions are authorization.
The simplest authorization model is role-based access control (RBAC). Users are assigned roles (admin, editor, viewer), and each role has a set of permissions. An admin can do everything. An editor can create and modify content. A viewer can only read. This works well for simple applications but breaks down when permissions depend on context: "you can edit your own projects but not other people's projects" is hard to express with roles alone.
For more complex scenarios, teams use attribute-based access control (ABAC) or relationship-based access control (ReBAC). ABAC uses attributes (user department, resource owner, time of day) to make decisions. ReBAC uses relationships (owner, member, viewer) between users and resources. Google Zanzibar is the ReBAC system that powers permissions for Google Drive, YouTube, and Google Cloud. Authorization is closely tied to SSO and OAuth for identity management. Tools like SpiceDB and Oso bring similar capabilities to other applications.
Examples
A project management tool implements role-based permissions.
The application has three roles: Owner, Member, and Guest. Owners can delete the workspace, manage billing, and invite members. Members can create and edit projects, assign tasks, and comment. Guests can view projects but cannot modify anything. The authorization check happens on every API request: the middleware loads the user's role for the current workspace and verifies the role permits the requested action.
A healthcare platform enforces document-level authorization.
Doctors can view records for their own patients but not other doctors' patients. The authorization system checks: is the requesting doctor listed as the attending physician for this patient? This is relationship-based authorization. It cannot be expressed as a simple role. The system uses a policy engine that evaluates the relationship between the user and the specific resource on every request.
A SaaS application uses Supabase Row Level Security.
Instead of checking permissions in application code, the team defines RLS policies directly in PostgreSQL. The policy says: users can only select rows where the user_id column matches their authenticated user ID. Even if a bug in the application code tries to return all users' data, the database enforces the policy and returns only the requesting user's data. Authorization is enforced at the data layer.
In practice
Read more on the blog
Frequently asked questions
What is the difference between RBAC and ABAC?
RBAC (role-based access control) assigns permissions to roles, then assigns roles to users. It answers: does this user's role allow this action? ABAC (attribute-based access control) evaluates attributes of the user, the resource, and the context. It answers: given these attributes, is this action allowed? RBAC is simpler: admin can delete. ABAC is more flexible: users in the engineering department can delete resources they created during business hours. Start with RBAC. Switch to ABAC when your permission rules become too complex for roles to express.
Should authorization logic go in the application or the database?
Both, ideally. Application-level authorization (middleware checks, policy engines) handles complex business rules and provides clear error messages. Database-level authorization (Row Level Security in PostgreSQL) is a safety net that prevents data leaks even when application code has bugs. Think of database authorization as the last line of defense. If an application bug bypasses the middleware check, RLS still prevents unauthorized data access. Defense in depth.
Related terms
The process of verifying who a user is, typically through credentials like a password or token.
An open standard that lets users grant third-party apps limited access to their accounts without sharing passwords.
Single sign-on: one login that grants access to multiple applications without signing in separately to each.
A unique string that identifies and authenticates an application or user when making API requests.
Application programming interface: a defined way for software programs to communicate with each other.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.