We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Security Architecture
Role-Based Access Control: assigns permissions to roles (admin, editor, viewer), then assigns roles to users. Simpler to manage than per-user permissions.
In short
Role-Based Access Control (RBAC) is an authorization model where permissions are attached to named roles such as admin, editor, or viewer, and users are granted access by being assigned one or more of those roles instead of having permissions set on them individually. When a user's job changes you swap their role rather than editing a long list of per-user grants, which keeps access decisions consistent and easy to audit.
In short
Role-Based Access Control (RBAC) is an authorization model where permissions are attached to named roles such as admin, editor, or viewer, and users are granted access by being assigned one or more of those roles instead of having permissions set on them individually. When a user's job changes you swap their role rather than editing a long list of per-user grants, which keeps access decisions consistent and easy to audit.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers RBAC across a run of lessons, not one page. These 4 alone are about 68 minutes of step-by-step reading, every one with a quiz.
Assigning permissions to roles instead of individuals, the most widely used access control model in production systems.
Controlling what authenticated users are allowed to do: permissions, roles, and access policies.
Attaching permission lists directly to resources, who can do what to this specific object.
Restricting access based on time windows, business hours, maintenance windows, temporary grants, and expiring permissions.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Role-Based Access Control (RBAC)pay once,
yours for life
RBAC is a way of answering one question: is this user allowed to do this action on this thing? Instead of writing a rule for every user, you define a small set of roles, attach permissions to each role, and then assign roles to users. A permission is usually a verb plus a resource, like read:invoices or delete:user.
The core relationship has three layers. Users are assigned to roles. Roles hold permissions. Permissions describe what can be done. A user inherits every permission of every role they hold, so the access check becomes: does any role this user has contain the permission being requested?
This indirection is the whole point. A company with 5,000 employees and 200 distinct permissions does not manage a million user-to-permission links. It manages maybe 30 roles, and each new hire gets one or two role assignments. NIST researchers first described RBAC in 1992, it became a formal ANSI standard in 2004, and it is still the default model in almost every enterprise system.
At its simplest, RBAC needs three tables: users, roles, and permissions, plus two join tables for user_roles and role_permissions. An authorization check joins through these: given a user id and a requested permission, the system asks whether a row exists linking that user to a role that holds that permission.
Many systems add role hierarchies so that a senior role inherits everything a junior role has. A Manager role might include the Employee role, so you define the manager permissions once and inherit the rest. This keeps role definitions small and avoids copy-pasting permission lists.
In practice the role assignments are encoded so the check is fast. After login the user's roles often get baked into a signed JWT or session, so most requests verify access in memory without a database round trip. Permission-to-role mappings are usually cached and refreshed on change, because they are read constantly and written rarely.
Use RBAC when access maps cleanly to job functions and the same access applies to everyone in that function. Internal tools, admin dashboards, SaaS team accounts, and Kubernetes clusters all fit this shape well. It is simple to reason about, easy to audit, and reviewers can answer who can do what by reading a short list of roles.
The classic failure mode is role explosion. The moment access depends on context, like region, department, or ownership of a specific record, teams start creating roles like editor_us_west_finance. You can end up with more roles than users, which defeats the purpose.
When you need per-record or contextual rules, RBAC alone is the wrong tool. Attribute-Based Access Control (ABAC) makes decisions from attributes such as the user's department and the document's owner, and policy engines like Open Policy Agent express this directly. A common production pattern is RBAC for the coarse layer (can this user reach the billing area at all) plus ABAC or ownership checks for the fine layer (can they see this specific invoice).
Take a publishing platform. You define three roles. Viewer can read:articles. Editor inherits Viewer and adds write:articles and submit:review. Admin inherits Editor and adds publish:articles, manage:users, and delete:articles.
A new writer joins and you assign them Editor. They can immediately read, write, and submit articles for review, with no individual permissions touched. When they get promoted to managing editor, you assign Admin and remove Editor, and their access changes in one step.
When the writer leaves, you delete their role assignments and every permission disappears at once. There is no hunting through scattered grants to make sure nothing was missed, which is exactly what auditors and SOC 2 reviewers want to see.
Kubernetes
Ships RBAC as the primary authorization mode: Roles and ClusterRoles hold verbs on resources, bound to users or service accounts via RoleBindings.
AWS IAM
Uses RBAC-style roles and managed policies to control which principals can call which API actions on which resources.
GitHub
Repository and organization access is role-based: Read, Triage, Write, Maintain, and Admin roles each carry a fixed permission set.
PostgreSQL
Database privileges are managed through roles that can be granted to users and to other roles, with inheritance built in.
RBAC grants access based on roles a user holds, so the decision is essentially does this user have a role with this permission. ABAC decides from attributes of the user, the resource, and the environment, like department, record owner, or time of day. RBAC is simpler and easier to audit; ABAC handles fine-grained and contextual rules that RBAC cannot express without role explosion. Many systems combine both.
The NIST model defines three: role assignment (a user can act only through a role they are assigned), role authorization (a user's active role must be one they are authorized to hold), and permission authorization (a user can use a permission only if it belongs to their active role). Together they guarantee access always flows through roles.
Role explosion is when contextual access needs cause you to create huge numbers of narrow roles, like editor_finance_emea, until you have more roles than users. Avoid it by keeping RBAC for coarse job-function access and layering attribute or ownership checks for fine-grained rules, often with a policy engine such as Open Policy Agent.
Yes. A user can hold multiple roles and inherits the union of all their permissions. This is normal, for example a person who is both an Editor and a Billing Admin. Some high-security systems add separation of duties constraints that forbid certain role combinations, like the same user being both a payment requester and a payment approver.
After authentication, roles are commonly embedded in a signed session or JWT so most requests can authorize in memory without a database lookup. The mapping of roles to permissions is typically stored in the database and cached, since it is read constantly but changed rarely.
ABAC
Attribute-Based Access Control: grants permissions based on attributes (user department, resource type, time of day, IP range). More flexible but more complex than RBAC.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
SSL/TLS
Cryptographic protocols that encrypt data in transit between client and server. TLS is the modern successor to SSL. The 'S' in HTTPS.
CORS
Cross-Origin Resource Sharing: a security mechanism that controls which domains can access your API. The browser enforces it; the server configures it.
This page explains the idea. The "Role-Based Access Control (RBAC)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Role-Based Access Control (RBAC) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about RBAC in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
