What is authorization?

Authentication vs. authorization

These get conflated all the time. They're not the same thing, and confusing them is the root of a surprising number of security incidents.

Authentication answers the question "who is making this request?". Logging in with a password is authentication. Showing a passport is authentication. The answer is an identity — a user ID, a service account, a token.

Authorization answers the question "is this identity allowed to do this thing on this resource?". Once you know who someone is, you still need to decide whether they can read this document, edit that record, or delete this account. Authorization is the decision; authentication just provides the input.

A single login (one authentication) might trigger thousands of authorization checks over the lifetime of a session — every page view, every API call, every database read. That's why the performance characteristics of an authorization system matter so much more than people expect.

RBAC — Role-based access control

RBAC is the model most people learn first. You group permissions into roles (Admin, Editor, Viewer), then assign roles to users. A user's permissions are the union of the permissions attached to their roles.

RBAC is great for org-chart authorization: HR can edit employees, Engineering can deploy services, Sales can view contracts. It's simple to reason about and easy to audit because the answer to "what can this user do" is just "look up their roles."

Where RBAC falls short

RBAC explodes the moment your authorization is per-resource rather than per-org. "Alice can edit Document 1234 but only view Document 5678" is not a role — it's a relationship to a specific resource. Modeling that in RBAC requires either inventing a role per (user, resource) pair (combinatorial explosion) or layering something else on top of RBAC. Most teams reach this limit faster than they expect.

ReBAC — Relationship-based access control

ReBAC models authorization as a graph of relationships between users and resources. Alice is an editor of Document 1234. Document 1234 lives in Folder X. Bob is a member of Team Y, and Team Y has viewer access to Folder X. Bob's permission to read Document 1234 is derived by traversing the graph.

Google introduced this model in their 2019 Zanzibar paper, which described how Google handles authorization at planet scale. ReBAC is the model behind Google Drive's sharing, GitHub's repo access, Notion's permissions, and most modern collaboration software.

Where ReBAC falls short

The graph traversal is computationally non-trivial. A naive implementation will check permissions in milliseconds; a production-grade one needs careful indexing, caching, and consistency design. ReBAC also doesn't naturally express attribute-driven rules ("only allow access during business hours from a managed device") — for that, you need ABAC.

ABAC — Attribute-based access control

ABAC makes the authorization decision a function of attributes — properties of the user, the resource, the action, and the request context. "Allow if user.department equals resource.department and request.time is within business hours and request.device.is_managed is true."

ABAC is what regulated industries reach for when policy needs to depend on context. Healthcare authorization often depends on the patient relationship and the clinician's current role. Financial authorization depends on transaction value, time of day, and geographic origin.

Where ABAC falls short

Pure ABAC is hard to audit because the decision depends on values that change at request time. "Why was this access allowed yesterday at 2:14 PM?" requires reconstructing the attributes that were true at that exact moment. Without a strong audit log, ABAC becomes opaque — exactly the wrong property for compliance.

Why most real systems need all three

Real-world applications usually need all three models, often inside the same authorization decision. A SaaS product might use RBAC for org-level roles (Admin vs Member), ReBAC for per-document sharing (Alice is editor of this doc), and ABAC for contextual rules (deny edits outside business hours from unmanaged devices).

Most systems handle this by running RBAC, ReBAC, and ABAC in three separate subsystems that gradually drift apart — different policy languages, different audit logs, different consistency models. That's how teams end up with three sources of truth and a quarterly audit ritual to reconcile them.

InferaDB unifies all three in a single declarative policy language with one audit log. Roles, relationships, and attributes are first-class citizens in the same schema, so a permission check traverses all three in a single decision. One authorization layer, one audit trail.

Why latency matters

Authorization runs in the hot path of every request. A typical web page view triggers one or two checks. A typical API call triggers three to five. An AI agent action triggers thirty or more — one per principal it acts on behalf of, one per tool it invokes, one per artifact it touches.

At thirty checks per action, the difference between a 5 ms authorization system and a 3 μs system is the difference between 150 ms of latency overhead and 0.1 ms. The first number ruins user experience; the second number is invisible. Authorization latency isn't a tuning concern — it's a product constraint.

Why the audit log matters

For most regulated industries, the audit log is the compliance posture. Auditors don't take "we have access controls" on faith; they ask for evidence that the access controls were enforced correctly at every relevant moment in time.

The standard a modern audit log has to meet is independent verifiability — the auditor must be able to prove the integrity of the record without trusting the vendor. That requires cryptographic techniques (hash chains, signatures, Merkle proofs) built into the audit subsystem from day one. Bolting verifiable audit onto a traditional database is hard; that's why most systems still rely on mutable logs and hope nobody asks.