Prerequisites

The Authorization Question

Authentication establishes who is making a request. Authorization decides whether that identity may perform a specific action on a specific resource. These are separate decisions, and conflating them is a persistent source of vulnerabilities.

Every authorization model is ultimately a way of answering that question consistently, at scale, and in a form that humans can reason about and auditors can verify.

Role-Based Access Control

RBAC assigns permissions to roles and roles to users. Rather than granting capabilities to individuals, the system groups related permissions into a named role that reflects a job function.

Data Model

CREATE TABLE roles (
    role_id     BIGINT PRIMARY KEY,
    role_name   VARCHAR(80) NOT NULL UNIQUE,
    description TEXT        NULL
);

CREATE TABLE permissions (
    permission_id   BIGINT PRIMARY KEY,
    permission_name VARCHAR(120) NOT NULL UNIQUE,
    resource_type   VARCHAR(80)  NOT NULL,
    action          VARCHAR(40)  NOT NULL
);

CREATE TABLE role_permissions (
    role_id       BIGINT NOT NULL,
    permission_id BIGINT NOT NULL,
    PRIMARY KEY (role_id, permission_id)
);

CREATE TABLE user_roles (
    user_id     BIGINT      NOT NULL,
    role_id     BIGINT      NOT NULL,
    scope_type  VARCHAR(40) NULL,
    scope_id    VARCHAR(80) NULL,
    granted_at  TIMESTAMP   NOT NULL,
    granted_by  BIGINT      NOT NULL,
    expires_at  TIMESTAMP   NULL,
    PRIMARY KEY (user_id, role_id, scope_type, scope_id)
);

The scope columns matter more than they first appear. Without them, a role applies globally, which is rarely what a multi-tenant or project-based system actually needs.

SELECT DISTINCT p.permission_name
FROM user_roles ur
JOIN role_permissions rp
    ON rp.role_id = ur.role_id
JOIN permissions p
    ON p.permission_id = rp.permission_id
WHERE ur.user_id = :user_id
  AND (ur.expires_at IS NULL OR ur.expires_at > CURRENT_TIMESTAMP)
  AND (ur.scope_type IS NULL
       OR (ur.scope_type = :scope_type AND ur.scope_id = :scope_id));

Role Hierarchies

Roles frequently inherit from one another, so a senior role receives everything a junior role has plus additional permissions.

Role Explosion

RBAC degrades when permissions must vary by dimensions that roles cannot express. Teams respond by creating increasingly specific roles, and the count grows multiplicatively.

If roles must vary across region, department, and clearance level, the number of distinct roles becomes the product of those dimensions rather than their sum. Four regions, five departments, and three clearance levels already produce sixty roles for what is conceptually one job function.

Attribute-Based Access Control

ABAC evaluates policies against attributes of the subject, the resource, the action, and the environment. Instead of asking which role the user holds, it asks whether the current facts satisfy a written rule.

Example Policy

{
    "policyId": "POL-0042",
    "description": "Finance staff may read regional reports during business hours from managed devices.",
    "effect": "Permit",
    "target": {
        "action": "report.read",
        "resourceType": "financial-report"
    },
    "conditions": [
        { "attribute": "subject.department", "operator": "equals", "value": "finance" },
        { "attribute": "subject.employmentStatus", "operator": "equals", "value": "active" },
        { "attribute": "resource.region", "operator": "equalsAttribute", "value": "subject.region" },
        { "attribute": "resource.classification", "operator": "in", "value": ["internal", "confidential"] },
        { "attribute": "environment.deviceManaged", "operator": "equals", "value": true },
        { "attribute": "environment.authLevel", "operator": "equals", "value": "mfa" }
    ]
}

A single policy replaces what RBAC would express as one role per region. The varying dimension became a comparison between a subject attribute and a resource attribute.

RBAC Compared to ABAC

Relationship-Based Access Control

A third model, ReBAC, decides access from relationships between subjects and resources. It suits systems where permission flows through containment or sharing, such as documents inside folders inside workspaces.

{
    "tuples": [
        { "subject": "user:4821", "relation": "owner",  "object": "document:9f2b" },
        { "subject": "user:5137", "relation": "editor", "object": "folder:project-x" },
        { "subject": "folder:project-x", "relation": "parent", "object": "document:9f2b" },
        { "subject": "group:finance", "relation": "viewer", "object": "folder:project-x" },
        { "subject": "user:6042", "relation": "member", "object": "group:finance" }
    ]
}

Authorization Architecture

Separating the decision point from the enforcement point keeps policy logic out of scattered application code.

Where to Enforce

Implementing the Check

async function authorize(context) {
    const { subject, action, resource, environment } = context;

    const decision = await policyEngine.evaluate({
        subject: {
            id: subject.id,
            roles: subject.roles,
            department: subject.department,
            region: subject.region,
            clearance: subject.clearance
        },
        action: action,
        resource: {
            id: resource.id,
            type: resource.type,
            ownerId: resource.ownerId,
            region: resource.region,
            classification: resource.classification
        },
        environment: {
            authLevel: environment.authLevel,
            deviceManaged: environment.deviceManaged,
            requestTime: environment.requestTime
        }
    });

    await auditLog.record({
        subjectId: subject.id,
        action: action,
        resourceId: resource.id,
        decision: decision.effect,
        matchedPolicy: decision.policyId,
        reason: decision.reason,
        occurredAt: new Date().toISOString()
    });

    return decision;
}

Recording the matched policy alongside the outcome is what makes an authorization system explainable later. Without it, incident investigation becomes guesswork.

Applying It in an Endpoint

async function getFinancialReport(request, response) {
    const report = await reportRepository.findById(
        request.params.reportId
    );

    if (!report) {
        return response.status(404).json({ error: "not_found" });
    }

    const decision = await authorize({
        subject: request.principal,
        action: "report.read",
        resource: report,
        environment: request.securityContext
    });

    if (decision.effect !== "Permit") {
        return response.status(404).json({ error: "not_found" });
    }

    return response.json(report);
}

Authorization in List Queries

Checking each record after retrieval breaks pagination and wastes work. The filter must be pushed into the query so that counts and page boundaries remain correct.

SELECT r.report_id,
       r.title,
       r.region,
       r.classification,
       r.created_at
FROM financial_reports r
WHERE r.region = :subject_region
  AND r.classification IN ('internal', 'confidential')
  AND (
        r.owner_id = :subject_id
        OR EXISTS (
            SELECT 1
            FROM report_shares s
            WHERE s.report_id = r.report_id
              AND s.principal_id = :subject_id
        )
      )
ORDER BY r.created_at DESC
LIMIT :page_size OFFSET :page_offset;

The same predicates must be applied to search indexes and analytics views. A derived store that omits them will leak records that the primary database correctly protects.

Performance and Caching

Authorization runs on every request, so its cost is multiplied across the entire system. Attribute gathering, not policy evaluation, is usually the expensive part.

Combining Rules

When multiple policies apply, the system needs a defined rule for resolving them.

Least Privilege and Separation of Duties

SELECT ur.user_id,
       r.role_name,
       ur.granted_at,
       ur.expires_at
FROM user_roles ur
JOIN roles r ON r.role_id = ur.role_id
WHERE r.role_name IN ('administrator', 'security-admin')
  AND ur.expires_at IS NULL
ORDER BY ur.granted_at;

Queries like this surface permanent privileged grants, which are usually the highest-value target in an environment.

Threats and Mitigations

Monitoring and Auditing

Choosing a Model

Common Design Mistakes

System Design Interview Discussion

Implementation Checklist

Knowledge Check

Summary

RBAC groups permissions into roles that map to job functions. It is understandable, fast to evaluate, and easy to review, but it degrades into role explosion when permissions must vary by region, ownership, classification, or context.

ABAC evaluates policies against subject, resource, action, and environment attributes. It expresses fine-grained and contextual rules without multiplying roles, at the cost of higher evaluation complexity and harder enumeration of who holds access.

ReBAC decides from relationships and suits hierarchical sharing. Most substantial systems combine models: roles for administrative capability, relationships for content, and attributes for contextual restrictions.

Regardless of model, the enforcement discipline is constant. Deny by default, check the specific resource, enforce on the server, push filters into queries, carry permissions into derived stores, fail closed on error, and record enough detail to explain every decision afterwards.