Authorization Models

Once a request is authenticated, authorization decides what it may do. This is the 403 half of the AuthN/AuthZ split from lesson one. Two models dominate, and they answer the question at different granularities.

RBAC: Role-Based Access Control

Permissions are grouped into roles; users are assigned roles. The check asks "does this user's role include this permission?"

const rolePermissions = {
  admin:  ["read", "write", "delete"],
  editor: ["read", "write"],
  viewer: ["read"],
};

function roleAllows(user, action) {
  return rolePermissions[user.role]?.includes(action) ?? false;
}

Simple, easy to audit, and enough for most apps. Its limit is granularity: roles describe kinds of users, not relationships to specific resources. "An editor can edit" is easy; "an editor can edit only documents in their own department" forces you to invent ever-narrower roles (editor-marketing, editor-sales), and they multiply fast. That's the classic role explosion Role explosion The problem that occurs when RBAC requirements get so specific that you end up with a large number of increasingly narrow roles to cover every case. .

ABAC: Attribute-Based Access Control

ABAC ABAC Attribute-Based Access Control: access decisions are based on attributes of the user, the resource, and the context (time, location, IP). More expressive than RBAC but also more complex to reason about. decides from attributes evaluated at request time: attributes of the user, the resource, and the context (time, location, IP):

// "You can edit a doc if you own it, or you manage the team that owns it."
function canEditDocument(user, doc) {
  return user.id === doc.ownerId
      || (user.dept === doc.dept && user.role === "manager");
}

This expresses rules RBAC can't reach without exploding into special-case roles: ownership, team membership, "business hours only," "same region." The cost is complexity: policies are harder to enumerate and reason about than a flat list of roles.

Underneath, the two models are answering different questions. RBAC asks "who are you?" once; ABAC asks "what's your relationship to this thing, right now?" on every request. That one difference drives every row:

The audit row is the sleeper. "Show me everyone who can delete customer records" is a compliance question you will be asked, and RBAC answers it with a query while ABAC answers it with a research project. That's why the expressiveness of ABAC isn't free even when the policies are simple.

So don't pick one. Use RBAC for the broad strokes, the coarse buckets you want to audit at a glance ("is this an admin?"), and reach for ABAC only where roles genuinely can't express the rule: ownership, team membership, "business hours only." Every ABAC policy you add is auditability you're spending; make sure the rule is worth it.

So far everything, login, credential, roles, has lived inside one app. The next lesson breaks that boundary: what happens when the data a user wants to share lives in someone else's system.