We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Authentication tells you the request came from alice@example.com. But Alice is a junior developer. Should she be able to delete the production database? Access other users' personal data? Modify billing settings? Deploy to production on a Friday at 5pm?
Without authorization, every authenticated user has the same access, which means every user has all access. A compromised account becomes a skeleton key. A disgruntled employee can access anything. A misconfigured service account can modify resources it should never touch.
Authorization answers: "Now that I know who you are, what are you allowed to do?" It maps identities to permissions. Alice can read and write code in the dev environment. Bob can deploy to staging. Only Carol, the database admin, can run DDL queries in production. Nobody can delete the production database without two-person approval.
Capital One's 2019 breach exposed 106 million customer records because a WAF role had overly broad permissions to access S3 buckets. The attacker exploited a server-side request forgery vulnerability, but the real failure was authorization: the compromised service had permissions it never should have had. Every serious data breach involves an authorization failure, either someone got access they should not have, or an over-permissioned account was compromised.
There are four major authorization models. Most applications need RBAC. Some need ABAC. Very few need ReBAC, but the ones that do (Google Drive, Notion, Airbnb) cannot function without it.
RBAC (Role-Based Access Control) groups permissions into roles: Admin, Editor, Viewer. You define 5-15 roles, assign permissions to each role, and assign roles to users. When Alice changes teams, you change her role, not her individual permissions. AWS IAM, , and most SaaS applications use RBAC. The weakness is role explosion: if you end up with 200 roles to handle every edge case, you have lost the simplicity benefit.
ABAC (Attribute-Based Access Control) evaluates policies based on attributes of the user, the resource, and the environment. "Allow if user.department == resource.department AND time is within business hours AND user.clearance >= resource.classification." ABAC handles context-dependent policies that RBAC cannot. Healthcare systems use ABAC for HIPAA compliance. Open Policy Agent (OPA) and AWS Cedar are popular policy engines.
ReBAC (Relationship-Based Access Control) models access as relationships in a graph. "Alice is an editor of Document X, which is in Folder Y, which Alice owns." Access is determined by traversing the relationship graph. Google published the Zanzibar paper in 2019 describing how they handle authorization for Drive, Calendar, and Cloud. SpiceDB and Ory Keto are open-source implementations.
ACL (Access Control Lists) assign permissions directly per resource per user. Unix file permissions (rwxr-xr--) are an ACL. Simple and intuitive for a few dozen files, but managing ACLs across millions of objects is a maintenance nightmare.