Authorization Strategies

Choosing the right authorization strategy is one of the most consequential architectural decisions an IAM architect makes. The wrong choice leads to administrative overhead, security gaps, or rigid systems that cannot adapt to changing business requirements.

This page provides a decision framework for selecting and combining authorization models based on your organisation’s requirements, architecture constraints, and maturity level.

Authorization Model Spectrum

Authorization models form a spectrum from simple, ownership-based models to sophisticated, policy-driven systems:

Simple ────────────────────────────────────────────────────────────→ Complex
  DAC ─→ MAC ─→ RBAC ─→ RBAC+ABAC ─→ ABAC ─→ PBAC ─→ ReBAC
  (coarse)                                                  (fine-grained)
  (low admin)                                             (high admin)
  (low flexibility)                                    (high flexibility)

Discretionary Access Control (DAC)

Concept: The resource owner decides who can access their resources.

Examples: Unix file permissions (chmod), Windows NTFS permissions, Google Drive sharing.

Characteristics:

• Decentralised — resource owners grant/revoke access
• Simple to implement — per-resource ACLs
• Poor auditability — no central record of who has access to what
• Does not scale — each resource managed individually
• Vulnerable to privilege escalation — users can grant access to others

Best for: File systems, document collaboration, small teams (< 50 people).

Mandatory Access Control (MAC)

Concept: A central authority assigns security labels to subjects and objects. Access is determined by comparing labels against a fixed policy.

Examples: SELinux, AppArmor, Bell-LaPadula (confidentiality), Biba (integrity).

Characteristics:

• Centralised — label definitions controlled by security administrators
• Non-discretionary — users cannot override access decisions
• Strong theoretical foundation — mathematical models proven correct
• Rigid — difficult to adapt to changing requirements
• High administrative overhead — every resource needs a label

Best for: Military, government classified systems, mandatory data protection.

Hybrid Authorization Patterns

The most effective enterprise authorization strategies combine multiple models to leverage the strengths of each:

RBAC with ABAC Constraints

The most common hybrid pattern. Use RBAC for broad job-function access, then apply ABAC to constrain that access based on context.

Example: A “Healthcare Provider” role (RBAC) can access patient records, but only for patients assigned to their department during their shift (ABAC constraint).

# RBAC base: role grants access
GRANT access IF user.role == "healthcare_provider"

# ABAC constraint: refine access
AND resource.department == user.department
AND resource.assigned_provider == user.id
AND environment.time BETWEEN user.shift_start AND user.shift_end

Attribute-Augmented RBAC

RBAC roles provide base permissions, but individual attributes can grant additional fine-grained access or impose restrictions.

Policy Delegation

Central policy team defines high-level policies (security, compliance, regulatory), while application teams define application-specific policies within that framework.

Central Policy (Enterprise)
  └── Data classification: "Confidential data must not leave the EU"
  └── MFA requirement: "All admin access requires phishing-resistant MFA"

Application Policy (App Team)
  └── "Contractors can view public documents"
  └── "Full-time employees with 'Finance' role can view financial reports"

Authorization in Microservices

Microservices architectures present unique authorization challenges:

Challenge 1: Decentralised Policy Enforcement

Each microservice must enforce authorization independently, leading to inconsistent policies across services.

Solution: Centralised policy engine (OPA) with sidecar or external deployment. Each service calls the policy engine for authorization decisions.

Challenge 2: Identity Propagation

The user’s identity must propagate through multiple service calls, each of which needs to authorize the action.

Solution: Token-based identity propagation with OAuth 2.0 token exchange. The initial token contains the user’s identity, and downstream services use token exchange to propagate the identity context.

    sequenceDiagram
    User->>API Gateway: Request + JWT
    API Gateway->>Auth Service: Validate JWT
    Auth Service->>API Gateway: User identity + claims
    API Gateway->>Service A: Request + propagated token
    Service A->>OPA: Is user allowed?
    OPA->>Service A: Permit/Deny
    Service A->>Service B: Request + propagated token
    Service B->>OPA: Is user allowed?
    OPA->>Service B: Permit/Deny
    Service B-->>User: Response
  

Challenge 3: Data-Level Authorization

Authorization often depends on which specific data a user can access, not just which endpoints they can call.

Solution: Row-level security with attribute-based filtering. The policy engine returns a filter condition that the data layer applies to queries.

API Authorization Patterns

Authorization Decision Flow

A well-designed authorization system follows a consistent decision flow:

Decision Framework: Which Authorization Model?

Key Takeaways

• Authorization models span a spectrum from DAC (simplest, least scalable) through RBAC (most widely adopted) to PBAC and ReBAC (most flexible, highest overhead)
• The most effective enterprise strategy combines RBAC for coarse-grained role-based access with ABAC for fine-grained contextual constraints
• Microservices authorization introduces challenges of decentralised enforcement, identity propagation, and data-level security — solved by centralised policy engines (OPA) and token-based identity propagation
• API authorization patterns range from simple API keys (low security) to mutual TLS and proof-of-possession tokens (very high security)
• A well-designed authorization system follows a consistent flow: intercept → resolve identity → collect attributes → evaluate policy → enforce decision → audit log
• Choosing the right authorization model depends on organisational size, regulatory requirements, architecture (monolith vs microservices), and data sensitivity — avoid over-investing beyond your current maturity level