Authorization Systems: The Complete Security Cheatsheet

Introduction: Understanding Authorization

Authorization is the security process that determines what a user, service, or application is permitted to do after their identity has been authenticated. It’s the mechanism that enforces access control policies and protects resources from unauthorized access. While authentication verifies identity (“who you are”), authorization determines permissions (“what you can do”). Well-designed authorization systems are critical for maintaining the principle of least privilege, protecting sensitive data, and ensuring regulatory compliance.

Core Authorization Concepts

Authorization Models Comparison

Role-Based Access Control (RBAC)

RBAC Components

• Users: Individual entities with identities
• Roles: Collections of permissions
• Permissions: Actions allowed on resources
• Operations: Actions (read, write, execute, etc.)
• Objects: Resources or data being protected

RBAC Implementation Levels

RBAC Pros and Cons

Pros:

• Simplified administration
• Reduced complexity in permission management
• Easily understandable structure
• Maps well to organizational structures
• Widely supported in software and frameworks

Cons:

• Limited contextual decisions
• Role explosion in complex environments
• Difficult to implement fine-grained permissions
• Static permission assignments
• Can be rigid for dynamic environments

Attribute-Based Access Control (ABAC)

ABAC Components

• Subjects: Users or systems requesting access
• Resources: Data or assets being protected
• Actions: Operations on resources
• Environment: Contextual information (time, location, etc.)
• Policies: Rules defining permission logic

ABAC Policy Structure

IF [subject attributes] AND [resource attributes] 
   AND [action attributes] AND [environment attributes]
THEN [permit/deny]

ABAC Implementation Approaches

ABAC Pros and Cons

Pros:

• Highly flexible and fine-grained control
• Can incorporate dynamic context
• Reduces administrative overhead
• Centralized policy management
• Supports complex business rules

Cons:

• More complex to implement and maintain
• Potential performance impact
• Policy conflicts can be difficult to detect
• Steep learning curve
• Requires careful attribute management

Claims-Based Access Control (CBAC)

CBAC Components

• Claims: Statements about the principal (user, service)
• Tokens: Containers for claims (JWT, SAML)
• Identity Provider: Source of claims and tokens
• Relying Party: Service that consumes tokens
• Claims Transformations: Rules for deriving new claims

Token Structure (JWT Example)

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "roles": ["editor", "user"],
  "department": "marketing",
  "exp": 1605447736,
  "iss": "https://idp.example.com"
}

CBAC Pros and Cons

Pros:

• Works well in distributed systems
• Supports single sign-on
• Reduced back-end queries
• Portable across services and domains
• Supports federation

Cons:

• Revocation challenges
• Token size limitations
• Potentially sensitive data in tokens
• Requires proper token validation
• Clock synchronization issues

Other Common Authorization Models

Relationship-Based Access Control (ReBAC)

• Based on relationships between entities
• Common in social networks (friend, follower, etc.)
• Extends to organizational relationships
• Supports transitive relationships
• Examples: Google Drive, Facebook privacy

Policy-Based Access Control (PBAC)

• Centralized policy definitions
• Abstracts authorization logic from application code
• Often includes elements of RBAC and ABAC
• Supports policy versioning and auditing
• Examples: AWS IAM, OPA (Open Policy Agent)

Mandatory Access Control (MAC)

• System-enforced policies (not user discretion)
• Based on classification levels and clearances
• Often used in military and government
• Strictly hierarchical
• Examples: SELinux, TrustedSolaris

Discretionary Access Control (DAC)

• Resource owners control permissions
• Users can delegate access to others
• Simpler but less secure than other models
• Examples: File system permissions, early ACLs

Authorization Decision Flow

1. Principal requests access to resource
2. Policy enforcement point (PEP) intercepts request
   • Extracts identity information
   • Extracts resource information
   • Extracts action information
   • Collects environmental context
3. Policy decision point (PDP) evaluates request
   • Retrieves applicable policies
   • Evaluates policies against request context
   • Makes authorize/deny decision
4. Policy enforcement point enforces decision
   • Allows or blocks access
   • May apply additional constraints (filters, transformations)
5. Decision is logged for audit purposes

Implementation Best Practices

Architectural Patterns

Implementation Principles

• Externalize authorization from application code
• Centralize policy definition and management
• Make default deny (whitelist approach)
• Design for least privilege
• Include comprehensive logging
• Plan for policy versioning
• Consider performance implications
• Design for scalability
• Support emergency access procedures
• Implement regular access reviews

Common Authorization Protocols & Standards

OAuth 2.0 Authorization Flows

OAuth 2.0 Scopes and Permissions

Scope Best Practices

• Make scopes granular but not too numerous
• Use hierarchical naming (e.g., files.read, files.write)
• Document scope meanings clearly
• Implement scope validation at resource servers
• Support dynamic scope registration for extensibility
• Consider time-bound or limited scopes
• Implement scope review in consent screens

Example Scope Hierarchy

profile                 # Access to basic profile
profile.read            # Read profile information
profile.write           # Update profile information
profile.write.basic     # Update basic information
profile.write.advanced  # Update advanced settings

Authorization in Microservices

Patterns

Service-to-Service Authorization Approaches

Authorization in Frontend Applications

SPA Authorization Patterns

Client-Side Authorization Considerations

• Never rely solely on client-side authorization
• Use to improve UX (hiding/showing UI elements)
• Always revalidate on the server
• Consider caching authorization decisions
• Balance security with performance
• Handle permission changes gracefully

Permission Design Best Practices

Permission Naming Conventions

• Use consistent naming pattern
• Consider resource:action format
• Group related permissions
• Keep names clear and understandable
• Avoid overlapping permissions
• Document permissions thoroughly

Example Permission Structures

# Flat structure
"create_document"
"read_document"
"update_document"
"delete_document"

# Resource-action structure
"document:create"
"document:read"
"document:update"
"document:delete"

# Hierarchical structure
"documents.*"          # All document permissions
"documents.create"     # Create documents
"documents.read"       # Read documents
"documents.update"     # Update documents
"documents.delete"     # Delete documents

Permission Grouping Strategies

• Resource-based (all document permissions)
• Function-based (all creation permissions)
• Role-based (editor permissions)
• Business process-based (approval workflow permissions)
• Organizational structure-based (department permissions)

Policy Languages and Engines

XACML Components

• PEP: Policy Enforcement Point
• PDP: Policy Decision Point
• PAP: Policy Administration Point
• PIP: Policy Information Point

OPA (Open Policy Agent)

• Uses Rego policy language
• JSON/YAML based policy definitions
• Supports various integration patterns
• Kubernetes-native authorization option

Custom Policy Languages

• AWS IAM Policy Language
• GCP IAM Policy
• Azure RBAC Policy
• Casbin policy language
• JBoss Drools

Example Policy Formats

XACML Policy (Simplified)

<Policy PolicyId="document-access">
  <Target>
    <Resources>
      <Resource>
        <ResourceMatch MatchId="string-equal">
          <AttributeValue>document</AttributeValue>
          <ResourceAttributeDesignator AttributeId="resource-type"/>
        </ResourceMatch>
      </Resource>
    </Resources>
  </Target>
  <Rule RuleId="allow-read" Effect="Permit">
    <Condition>
      <Apply FunctionId="string-equal">
        <ActionAttributeDesignator AttributeId="action-id"/>
        <AttributeValue>read</AttributeValue>
      </Apply>
    </Condition>
  </Rule>
</Policy>

OPA/Rego Policy

package authz

default allow = false

allow {
  input.method == "GET"
  input.path = ["documents", doc_id]
  doc_id = input.user.documents[_]
}

AWS IAM Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:username": "jane"
        }
      }
    }
  ]
}

Common Authorization Vulnerabilities

Authorization Testing Techniques

Logging and Monitoring

What to Log

• All access decisions (allow/deny)
• Policy evaluations
• Policy changes
• Role/permission assignments
• Privilege escalations
• Authentication context for decisions
• Resource identifiers
• Timestamps and source information

Monitoring Patterns

• Unusual access patterns
• Denied access attempts
• Permission changes
• Policy modifications
• Role assignments
• Privilege escalation
• Cross-tenant access attempts
• Unusual timing of operations

SIEM Integration

• Forward authorization logs to SIEM
• Correlate with authentication events
• Set up alerts for suspicious patterns
• Create dashboards for authorization activities
• Implement automated response procedures
• Establish retention policies for compliance

Compliance and Regulations

Authorization Decision Framework

1. Identify Authorization Requirements

   • Regulatory needs
   • Business requirements
   • Security posture
   • Scalability needs
   • Operational constraints

2. Select Authorization Model

   • Simple structure, limited roles? → RBAC
   • Complex conditions, many attributes? → ABAC
   • Distributed environment? → Claims-based
   • Social/sharing platform? → ReBAC
   • High security, classified info? → MAC

3. Choose Implementation Approach

   • Built-in application controls? → Embedded
   • Consistent enterprise policy? → Centralized service
   • Microservices architecture? → Dedicated auth service or sidecar

4. Select Technology Stack

   • Standard framework? → XACML, OPA
   • Cloud infrastructure? → Cloud provider IAM
   • Custom needs? → Custom policy engine
   • API-focused? → OAuth 2.0

Implementation Strategies by Scale

Small Applications

• Use framework-provided authorization
• Simple RBAC model
• Hardened authorization code
• Manual authorization testing
• Basic authorization logging

Medium Enterprise

• Centralized authorization service
• RBAC with some attribute-based rules
• Internal authorization API
• Automated authorization testing
• Enhanced logging and monitoring

Large Enterprise

• Enterprise authorization platform
• Hybrid RBAC/ABAC approach
• Standardized policy language
• Comprehensive authorization testing
• Advanced analytics and monitoring

Authorization in Specific Domains

Cloud Infrastructure

• Use cloud provider IAM
• Implement identity federation
• Use service accounts carefully
• Implement resource hierarchy
• Consider multi-account strategies

Microservices

• Consider token-based authorization
• Implement service mesh for service-to-service
• Design fine-grained permissions
• Centralize policy management
• Implement proper token validation

Mobile Applications

• Store tokens securely
• Implement certificate pinning
• Consider device posture
• Ensure server-side validation
• Implement proper token refresh

IoT Systems

• Use device identity
• Implement capability-based security
• Consider network segmentation
• Use mutual TLS authentication
• Implement device commissioning security

Continuous Evolution of Authorization

Modern Trends

• Zero Trust Security: Never trust, always verify
• Continuous Authorization: Ongoing evaluation vs. one-time
• Adaptive Access Control: Risk-based, contextual decisions
• Policy as Code: Treating policies like application code
• Machine Learning: Anomaly detection in authorization

Evolving Standards

• CAEP (Continuous Access Evaluation Protocol)
• RAR (Rich Authorization Requests)
• GNAP (Grant Negotiation & Authorization Protocol)
• ALFA (Abbreviated Language for Authorization)
• OAuth 2.1 (Simplification and security improvements)

Key Takeaways

1. Authorization is distinct from authentication but critically depends on it
2. No single model fits all needs – select the right model for your context
3. Principle of least privilege is fundamental to all authorization systems
4. Centralize policy management where possible for consistency
5. Externalizing authorization from application code improves maintainability
6. Never trust client-side authorization – always verify on the server
7. Comprehensive logging and monitoring are essential for security
8. Regular access reviews help maintain proper authorization over time
9. Design for flexibility as authorization requirements will change
10. Authorization is a continuous process, not a one-time implementation

Further Learning Resources

Standards Organizations

• OASIS (XACML)
• IETF (OAuth, JWT)
• OpenID Foundation (OpenID Connect)
• Cloud Security Alliance

Open Source Tools

• OPA (Open Policy Agent)
• Casbin (authorization library)
• Keycloak (Identity and Access Management)
• XACML engines (Balana, AuthzForce)
• JWT libraries (various languages)

Books and Articles

• “Designing Distributed Systems” by Brendan Burns
• “Identity and Data Security for Web Development” by Jonathan LeBlanc
• “OAuth 2.0: The Definitive Guide” by Aaron Parecki
• “Zero Trust Networks” by Evan Gilman and Doug Barth

Training and Courses

• SANS security courses (SEC01, SEC05)
• Cloud provider security training (AWS, GCP, Azure)
• OWASP security training
• Coursera and edX security specializations