Authorization Patterns

Imagine a massive corporate headquarters with thousands of employees. At the entrance, security guards verify each person's identity—checking badges, comparing faces to photos, perhaps even requiring a fingerprint scan. This is authentication: proving you are who you claim to be.

But once inside the building, a new challenge arises. Can this employee access the executive boardroom? Can they view payroll data? Can they modify the production database? Can they deploy code to live systems? This is authorization: determining what an authenticated entity is allowed to do.

In modern distributed systems, authorization is one of the most critical—and most commonly misunderstood—security concerns. A single authorization bypass can expose sensitive data to unauthorized users, allow privilege escalation attacks, or enable complete system compromise. Yet authorization is also extraordinarily complex, involving nuanced business rules, dynamic contexts, and intricate permission hierarchies that must be enforced consistently across dozens or hundreds of microservices.

Before diving into authorization patterns, we must establish an absolutely clear distinction between authentication and authorization. These terms are frequently confused, abbreviated identically (AuthN vs AuthZ), and sometimes incorrectly used interchangeably—even by experienced engineers.

Authentication (AuthN) answers the question: "Who are you?"

Authentication establishes identity. It verifies that a user, service, or system is genuinely who or what it claims to be. Authentication mechanisms include passwords, biometrics, cryptographic certificates, API keys, and multi-factor authentication. The output of authentication is an identity assertion—a claim that "this request comes from User X" or "this service is Service Y."

Authorization (AuthZ) answers the question: "What are you allowed to do?"

Authorization determines permissions. Given a verified identity, authorization decides whether that identity can perform a specific action on a specific resource. Authorization mechanisms include role-based access control, attribute-based policies, access control lists, and capability tokens. The output of authorization is a permit/deny decision for a specific operation.

The dependency relationship:

Authorization typically depends on authentication (you must know who someone is before deciding what they can do), but authentication never depends on authorization. This creates a natural flow:

Request → Authentication → Identity Established → Authorization → Permission Decision → Action Executed

However, this linear view oversimplifies reality. In complex systems, a single request might require multiple authorization decisions at different layers, and some authorization contexts might not require user authentication at all (e.g., anonymous users with limited permissions, or machine-to-machine communication with service identities).

Authorization systems revolve around a set of fundamental concepts that appear regardless of the specific pattern or implementation. Understanding this vocabulary is essential for designing and discussing authorization architectures.

The Authorization Question:

Every authorization decision can be framed as answering this question:

"Given subject S, can S perform action A on resource R, within context C?"

This is sometimes called the authorization tuple: (S, A, R, C) → {permit, deny}

Different authorization patterns provide different mechanisms for answering this question:

• Access Control Lists (ACLs) attach permissions directly to resources
• Role-Based Access Control (RBAC) groups permissions into roles assigned to subjects
• Attribute-Based Access Control (ABAC) evaluates policies against attributes of subjects, resources, and context
• Relationship-Based Access Control (ReBAC) derives permissions from relationships between entities

Each approach has distinct advantages for different use cases, as we'll explore in subsequent pages.

Effective authorization requires careful data modeling. The relationships between subjects, resources, permissions, and policies form the foundation of any access control system. Let's examine the key modeling decisions and patterns.

Subject Identity Model:

Subjects in an authorization system typically include:

• Users — Human beings with accounts, potentially from multiple identity providers
• Groups — Collections of users that share common access needs
• Service Accounts — Machine identities for automated processes and services
• API Clients — External applications authorized to call your APIs
• Anonymous — Unauthenticated actors with baseline permissions

Subjects can have multiple concurrent identities (a user might be part of several groups, have multiple roles, and be accessing from different devices). The authorization system must resolve these overlapping identities into coherent permission sets.

Resource Hierarchy Model:

Resources are rarely flat—they exist in hierarchies that affect permission inheritance:

Organization
├── Team A
│   ├── Project X
│   │   ├── Document 1
│   │   └── Document 2
│   └── Project Y
│       └── Document 3
└── Team B
    └── Project Z
        └── Document 4

Key modeling questions include:

• Do permissions granted at parent level automatically apply to children?
• Can child resources override or restrict parent permissions?
• How deep can the hierarchy go before performance degrades?
• How do you handle resources that belong to multiple parents?

Permission Granularity:

Permissions can be modeled at varying levels of granularity:

Coarse-grained: admin, editor, viewer

• Pros: Simple to understand and manage
• Cons: Limited flexibility, over-privileged users

Fine-grained: documents:read, documents:write, documents:delete, documents:share

• Pros: Precise access control, principle of least privilege
• Cons: Complex to manage, permission explosion

Instance-level: documents:12345:read, documents:12345:write

• Pros: Per-resource access control
• Cons: Massive permission data, performance challenges

Most real-world systems use a hybrid approach: coarse-grained roles for general access patterns, with fine-grained permissions for sensitive operations and instance-level controls for high-value resources.

Authorization becomes significantly more complex in distributed architectures. What seems straightforward in a monolithic application—checking if a user can perform an action—becomes a distributed systems challenge when microservices are involved.

The Distributed Authorization Challenges:

Architectural Patterns for Distributed Authorization:

The Zero Trust Imperative:

Modern authorization must embrace zero trust principles: never assume a request is authorized just because it came from an internal service or passed through a gateway. Every service should validate authorization independently, even for internal traffic. This defense-in-depth approach prevents lateral movement if any single service is compromised.

This means authorization checks are not optional—they're mandatory at every trust boundary in your architecture.

An authorization decision follows a specific lifecycle from request initiation through decision enforcement. Understanding this lifecycle helps identify where bottlenecks occur and where to optimize.

Phase 1: Request Interception

Authorization begins when a protected resource is accessed. Interception can occur at:

• API Gateway / Ingress controller (edge enforcement)
• Application middleware (framework-level enforcement)
• Service method (code-level enforcement)
• Database layer (row-level security)

The interception point determines what context is available and what latency is acceptable.

Phase 2: Context Assembly

Before making a decision, the authorization system gathers necessary context:

• Subject attributes: User ID, roles, groups, tenant, session data
• Resource attributes: Resource type, owner, classification, state
• Action attributes: Operation type, HTTP method, parameters
• Environmental attributes: Timestamp, IP, device, risk score

Context assembly can require database lookups, cache reads, or calls to external services. Efficient context assembly is often the key to authorization performance.

Phase 3: Policy Evaluation

With context assembled, policies are evaluated to reach a decision:

1. Identify applicable policies (based on subject, resource, action)
2. Evaluate each policy against the assembled context
3. Resolve conflicts if multiple policies apply
4. Return final decision: permit, deny, or not-applicable

Policy engines vary from simple if-then rules to sophisticated domain-specific languages like Rego (Open Policy Agent) or Cedar (AWS).

Phase 4: Decision Caching

To reduce latency, authorization decisions are often cached:

• Positive caching: Remember permit decisions to avoid re-evaluation
• Negative caching: Remember deny decisions (controversial—security vs. performance)
• TTL management: Balance freshness with performance
• Invalidation: Clear cache when policies or attributes change

Caching authorization decisions is inherently risky—stale cache entries can grant or deny access incorrectly.

Phase 5: Decision Enforcement

The final phase enforces the decision:

• Permit: Allow the action to proceed
• Deny: Return appropriate error (403 Forbidden) with minimal information
• Audit: Log the decision for compliance and debugging
• Obligations: Execute any required side effects (e.g., log sensitive access)

Authorization vulnerabilities are among the most dangerous and most common security flaws. OWASP consistently ranks broken access control as a top-10 vulnerability. Understanding failure modes helps design more robust systems.

Real-World Authorization Breach Example:

In 2021, a major social media platform experienced a data exposure incident where users could access private photos of other users by incrementing numeric photo IDs in API calls. The system authenticated users correctly but failed to verify that the requesting user had authorization to view each specific photo. This is a classic IDOR vulnerability.

The fix required implementing proper resource-level authorization: before returning any photo, verify that the requesting user has a relationship (friend, follower, owner) that grants access. This seemingly simple check requires efficient relationship queries at scale—millions of authorization checks per second.

Defensive Principles:

Authorization enforcement can occur at multiple layers of a system architecture. Each layer offers different trade-offs between security, performance, and development complexity. Defense-in-depth recommends enforcement at multiple points.

Layered Enforcement Example:

Consider a healthcare application where doctors access patient records:

1. Network layer: Firewall allows only authorized IP ranges to reach the service
2. API Gateway: Validates JWT tokens, ensures user is authenticated
3. Service middleware: Verifies user has 'physician' role
4. Business logic: Confirms physician is assigned to this patient's care team
5. Data layer: Row-level security filters records to only those the physician can see

An attacker would need to bypass all five layers to access unauthorized records. This defense-in-depth approach significantly raises the bar for successful attacks.

We've established a deep foundation for understanding authorization as a critical security concern in system design. Let's consolidate the key insights:

What's Next:

With this foundation in place, we'll explore specific authorization patterns in detail. The next page examines Role-Based Access Control (RBAC)—the most widely deployed authorization pattern, used everywhere from operating system permissions to enterprise SaaS applications. We'll explore how RBAC models permissions through roles, its strengths, its limitations, and best practices for implementation at scale.