You proved who you are at the door. Authentication is done. Now the system has to decide what you’re allowed to touch. Can you read this file? Edit that record? Delete the production database? That decision — authorization — is where access control models live. And picking the wrong model doesn’t just cause headaches. It causes breaches. Overpermissioned accounts are the bread and butter of lateral movement, privilege escalation, and data exfiltration. Every “insider threat” postmortem eventually lands on “they had access they shouldn’t have had.”

The TLDR

Authorization models define how systems decide who can do what. Discretionary Access Control (DAC) lets resource owners set permissions — flexible but chaotic. Mandatory Access Control (MAC) uses labels and clearance levels — rigid but strong in classified environments. Role-Based Access Control (RBAC) assigns permissions to roles — the industry default, but it suffers from role explosion at scale. Attribute-Based Access Control (ABAC) evaluates policies based on attributes of the subject, resource, action, and environment — powerful and granular but complex. Relationship-Based Access Control (ReBAC) makes authorization decisions based on the relationship between entities — ideal for collaborative platforms. The principle of least privilege (NIST SP 800-53 AC-6) underpins all of them: grant the minimum access necessary, nothing more.

The Reality

Most organizations start with RBAC because it’s intuitive. You’re an “Admin,” a “Manager,” or a “Viewer.” Permissions attach to the role, you assign people to roles, done. It works beautifully with 50 people and 5 roles. It falls apart at 5,000 people and 500 roles — a phenomenon known as role explosion. Suddenly you have roles like “East-Region-Senior-Finance-Reviewer-ReadOnly” and nobody remembers what half of them do. The NIST RBAC model (NIST SP 800-207) acknowledges this complexity and the need for more dynamic models.

The real-world pattern is messy. Organizations rarely use one pure model. They layer them — RBAC for broad strokes, ABAC for fine-grained decisions, custom exceptions for the edge cases that don’t fit either. And lurking underneath it all is the principle of least privilege, which everyone agrees with in theory and almost nobody enforces in practice. Access accrues. Roles accumulate. Nobody removes the permissions from the project you left six months ago. That drift is the attack surface.

How It Works

Discretionary Access Control (DAC)

DAC is the oldest model, and you use it every day without thinking about it. File permissions on Windows and Linux are DAC — the file owner decides who can read, write, or execute. Share a Google Doc with specific people? That’s DAC.

The core principle: the resource owner has discretion over access. This is flexible and intuitive, but it distributes security decisions to every person in the organization. One employee shares a sensitive document too broadly, and your access control is blown. DAC doesn’t scale to environments where centralized policy enforcement matters. NIST SP 800-12 describes DAC as suitable for low-sensitivity environments but insufficient for systems requiring strict access guarantees.

Mandatory Access Control (MAC)

MAC is the opposite philosophy. Access decisions are made by a central authority based on classification labels. Every object (file, database, network segment) gets a sensitivity label (Unclassified, Confidential, Secret, Top Secret). Every subject (person, process) gets a clearance level. The system enforces two rules:

This is the Bell-LaPadula model in action, developed for the Department of Defense in the 1970s. MAC shows up in SELinux, classified government networks, and environments where data sensitivity demands ironclad, non-discretionary controls. The tradeoff is rigidity — MAC systems are difficult to configure, difficult to change, and hostile to the kind of ad-hoc collaboration that modern workflows demand.

The Biba model is Bell-LaPadula’s mirror image, focused on integrity instead of confidentiality: no read down (don’t trust data from lower integrity levels) and no write up (don’t corrupt data at higher integrity levels).

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, and you assign people to roles. It was formalized by NIST in the INCITS 359 standard and remains the most widely deployed model in enterprise software.

The components:

RBAC’s strength is auditability. You can answer “what can this person do?” by looking at their roles. You can answer “who has access to this resource?” by examining which roles include that permission. These are critical questions for compliance frameworks like SOX, HIPAA, and PCI DSS.

RBAC’s weakness is role explosion. As organizations grow, the number of unique permission combinations multiplies. Every exception, every cross-functional project, every regional variation demands a new role. Large enterprises regularly end up with more roles than people. At that point, RBAC is no longer simplifying access management — it’s creating an unmanageable web of roles that nobody fully understands.

Attribute-Based Access Control (ABAC)

ABAC moves from static roles to dynamic policy evaluation. Instead of asking “what role does this person have?”, it asks “what attributes does this request have, and do they satisfy the policy?”

Attributes can describe anything:

An ABAC policy might say: “Allow access to patient records if the subject’s role is ‘Physician’ AND the subject’s department matches the patient’s care unit AND the request originates from the hospital network AND the current time is within the subject’s shift.” Try expressing that cleanly in RBAC.

NIST SP 800-162 provides the formal guide to ABAC. The standard defines the architecture: a Policy Enforcement Point (PEP) intercepts access requests, a Policy Decision Point (PDP) evaluates policies, a Policy Information Point (PIP) retrieves attribute values, and a Policy Administration Point (PAP) manages policies.

Policy engines like Open Policy Agent (OPA) and AWS Cedar are the modern implementation of ABAC. OPA uses the Rego policy language; Cedar uses a purpose-built language that’s formally verified for safety properties. Both decouple policy from application code — your application asks the policy engine “is this request allowed?” and gets a yes/no answer.

The tradeoff is complexity. ABAC policies are powerful but harder to audit than RBAC role assignments. Answering “what can this person access?” requires evaluating every policy against that person’s attributes — there’s no simple lookup table.

Relationship-Based Access Control (ReBAC)

ReBAC makes authorization decisions based on relationships between entities. “Can Alice edit this document?” depends on whether Alice is in the document’s editor list, or is a member of a group that owns the document, or is an admin of the organization that contains the group.

This is how Google Drive, GitHub, and most collaborative platforms actually work. The authorization model is a graph of relationships: users belong to teams, teams own repositories, repositories contain files. Permissions flow through the graph. Google’s Zanzibar paper formalized this approach, and open-source implementations like OpenFGA (originally from Auth0/Okta) and SpiceDB make it accessible.

ReBAC excels at modeling hierarchical, collaborative systems where permissions are contextual — your access depends on your relationship to the specific object, not on a global role. The challenge is that the relationship graph can get large and complex, and answering “who has access to what?” requires graph traversal rather than a table scan.

How It Gets Exploited

Permission Creep and Orphaned Access

The most common authorization failure isn’t a technical bypass — it’s accumulation. People change roles but keep their old permissions. Projects end but the shared folders stay open. Service accounts get created for a migration and never decommissioned. This is access creep, and it turns every organization into a sprawling attack surface over time. MITRE ATT&CK T1078 (Valid Accounts) is the technique — attackers don’t need to escalate privileges if the account they compromised already has excessive access.

Insecure Direct Object References (IDOR)

Authorization enforcement happens at the application layer, and developers mess it up constantly. An IDOR vulnerability occurs when an application exposes internal object references (like database IDs in URLs) and doesn’t verify that the authenticated person is authorized to access that specific object. Change /api/invoice/1234 to /api/invoice/1235 and suddenly you’re looking at someone else’s invoice. This is the OWASP Top 10 A01:2021 — Broken Access Control, and it’s the number one web application vulnerability category.

Privilege Escalation

Vertical escalation: an attacker with low-level access exploits a flaw to gain admin access. Horizontal escalation: an attacker accesses another person’s resources at the same privilege level. Both are authorization failures. MITRE ATT&CK T1068 (Exploitation for Privilege Escalation) catalogs the techniques — from kernel exploits to misconfigured sudo rules to confused deputy attacks.

Broken Separation of Duties

When one account or role can perform both sides of a sensitive transaction — request and approve, create and deploy, code and push to production — separation of duties is broken. Insider threats thrive in these environments. The 2011 UBS rogue trader incident is a textbook example: one person had access to both trading and risk management systems, enabling billions in unauthorized trades.

What You Can Do

Start with least privilege. Every account, every service, every role should have the minimum access needed to function. Not the access that’s “convenient.” Not the access “they might need someday.” The minimum. NIST SP 800-53 AC-6 is the control. Enforce it.

Conduct regular access reviews. Quarterly at minimum. Compare current access to current job function. Revoke everything that doesn’t match. Automate this with identity governance tools where possible, but do it manually if you must.

Enforce separation of duties. Identify critical workflows that require checks and balances, and ensure no single role can perform all steps. Map these constraints in your RBAC model or your ABAC policies.

Use policy-as-code. If your authorization logic lives in application code scattered across dozens of services, it’s unauditable. Centralize it with a policy engine like OPA or Cedar. Policies become testable, versionable, and reviewable.

Model before you build. Before implementing an authorization system, model your access patterns. If you have fewer than 50 roles and they map cleanly to job functions, RBAC is fine. If you need dynamic, context-aware decisions, ABAC is worth the investment. If your application is fundamentally about relationships between entities, look at ReBAC.

Sources & Further Reading