02.01 · Concept · Free
Authentication Is Not Authorization
Place RBAC, ABAC and ReBAC on one axis and pick the simplest of the three that can express your product's rules.
Curated for this lesson1/3
Permissions & Organizations
Role-based access control (RBAC) vs. Attribute-based access control (ABAC)
Directly compares RBAC and ABAC, the first two models on the lesson’s authorization-complexity axis.
Authentication proves identity; authorization decides permitted actions for that identity. RBAC fits rules based on named roles, ABAC fits rules based on properties of users, resources or requests, and ReBAC fits rules based on relationships such as ownership, membership, hierarchy or sharing. Choose the least expressive model that can represent the product rule.
What this lesson answers
- authentication versus authorization in product permissions
- when should I use RBAC ABAC or ReBAC
- how to choose an authorisation model
Notes
Authentication answers “who is this?” Authorization answers “what may this identity do?” Logging in, validating a token, or proving possession of a password only establishes an identity and maybe some facts about it. The permission decision is separate: can this user read this document, invite someone to this workspace, approve this payment, or administer this repository? Treating those as one step is how systems accidentally let “valid user” become “allowed user.”
RBAC, ABAC, and ReBAC can be placed on an axis from simpler to more expressive. RBAC says access comes from named roles such as admin, editor, or billing-manager. ABAC says access comes from attributes of the user, resource, action, or environment, such as department, region, document classification, plan tier, or time. ReBAC says access comes from relationships between subjects and objects, such as owner of this repo, member of this workspace, manager of this employee, or viewer through a shared folder’s parent.
The common misconception is that “more fine-grained” always means “better.” It is wrong because expressiveness has operational cost: more policy inputs, harder debugging, more edge cases, and more chances for inconsistent rules. If roles accurately describe your product’s permissions, use RBAC. If rules depend on properties, use ABAC. If rules depend on graphs of ownership, membership, sharing, hierarchy, or delegation, use ReBAC.
After this lesson, you should be able to look at a product rule and ask what information is needed to decide it. If the answer is only “what role does the user have?”, choose RBAC. If the answer is “what attributes do the user, resource, or request have?”, choose ABAC. If the answer is “how is this user connected to this object or organization?”, choose ReBAC.
References
Common questions
- Why is authentication not enough for access control?
- Authentication only establishes who the caller is, usually by checking a login, token or credential. It does not decide whether that identity may perform a specific action on a specific resource. A valid user still needs an authorisation decision for actions such as reading a document, inviting a member or administering a repository.
- When is RBAC the right authorisation model?
- RBAC is the right starting point when permissions map cleanly to named roles such as admin, editor or billing manager. If knowing the user’s role is enough to answer the access question, RBAC is simpler to operate and reason about than models that inspect many attributes or relationship paths.
- When do permissions need ReBAC instead of ABAC?
- Use ReBAC when the decision depends on how a subject is connected to an object or organisation. Examples include owners, workspace members, managers, delegated access, shared folders and inherited access through a hierarchy. ABAC handles properties; ReBAC handles graph-shaped product relationships.
Short definition: what is Authentication Is Not Authorization?