Authorization Patterns: The Complete Implementation Cheatsheet

Introduction: Understanding Modern Authorization

Authorization patterns determine how applications securely access resources on behalf of users. OAuth 2.0 has become the industry standard framework for authorization, enabling secure delegated access without sharing credentials. Proper implementation is crucial for maintaining security while providing seamless user experiences across web and mobile applications.

Core Authorization Concepts

OAuth 2.0 Roles

• Resource Owner: Entity granting access (typically the end-user)
• Client: Application requesting access to resources
• Authorization Server: Issues access tokens after authenticating resource owner
• Resource Server: Hosts protected resources, validates tokens

OAuth 2.0 Grant Types

Authorization Code Flow

+----------+     +----------+     +--------------+     +----------------+
|          |     |          |     |              |     |                |
| Resource |     | Client   |     | Auth Server  |     | Resource       |
| Owner    |     |          |     |              |     | Server         |
|          |     |          |     |              |     |                |
+----+-----+     +----+-----+     +------+-------+     +-------+--------+
     |                |                  |                     |
     | 1. Auth        |                  |                     |
     | Request        |                  |                     |
     |<---------------+                  |                     |
     |                |                  |                     |
     | 2. Authorize   |                  |                     |
     +--------------->|                  |                     |
     |                | 3. Auth Code     |                     |
     |                | Request          |                     |
     |                +----------------->|                     |
     |                |                  |                     |
     |                | 4. Auth Code     |                     |
     |                |<-----------------+                     |
     |                |                  |                     |
     |                | 5. Token Request |                     |
     |                | with Auth Code   |                     |
     |                +----------------->|                     |
     |                |                  |                     |
     |                | 6. Access Token  |                     |
     |                |<-----------------+                     |
     |                |                  |                     |
     |                | 7. Resource      |                     |
     |                | Request + Token  |                     |
     |                +------------------------------------>  |
     |                |                  |                     |
     |                | 8. Resource      |                     |
     |                |<------------------------------------+  |
     |                |                  |                     |

• Best for: Web applications with server-side component
• Security: High (PKCE recommended)
• Process:
  1. Client redirects user to authorization server
  2. User authenticates and consents to permissions
  3. Authorization server redirects user back with authorization code
  4. Client exchanges code for access token
  5. Client uses access token to access protected resources

Implicit Flow (Legacy)

• Best for: Legacy browser-based apps without server component
• Security: Lower (not recommended for new implementations)
• Process: Similar to authorization code but token returned directly in redirect URI

Client Credentials Flow

• Best for: Server-to-server authentication
• Security: High
• Process: Client authenticates directly with authorization server using client ID and secret

Resource Owner Password Credentials (ROPC)

• Best for: High-trust first-party applications (use sparingly)
• Security: Lower (exposes user credentials to application)
• Process: Application collects and forwards user credentials to authorization server

Device Code Flow

• Best for: Limited-input devices (TVs, IoT devices)
• Security: High
• Process: Device displays code for user to enter on secondary device

PKCE Extension (Proof Key for Code Exchange)

• Purpose: Prevents authorization code interception attacks
• Used with: Authorization Code Flow
• Process:
  1. Client generates random code_verifier
  2. Client creates code_challenge using SHA256
  3. Authorization request includes code_challenge
  4. Token request includes original code_verifier for validation

Token Types

Access Tokens

• Purpose: Short-lived credentials for accessing resources
• Format: Often JWT (JSON Web Token)
• Contains: Scopes, expiration, user info
• Security: Must be kept confidential, transmitted over HTTPS

Refresh Tokens

• Purpose: Obtain new access tokens without re-authentication
• Lifespan: Longer than access tokens
• Security: Must be stored securely, never exposed to browser

ID Tokens (OpenID Connect)

• Purpose: Contains authenticated user information
• Format: JWT
• Contains: User claims (profile, email, etc.)

Access Token Validation

JWT Validation Steps

1. Signature verification using public key or shared secret
2. Expiration check (exp claim)
3. Issuer validation (iss claim)
4. Audience check (aud claim)
5. Scope verification for required permissions

Introspection Endpoint

• Alternative validation method for opaque tokens
• Client sends token to authorization server
• Server returns token metadata (active status, scope, expiry)

Common Implementation Patterns

Single Sign-On (SSO)

• Allows one login to access multiple applications
• Often implemented with OpenID Connect + OAuth 2.0
• Uses centralized identity provider

Microservice Authorization

• Token propagation: Forward tokens between services
• Token exchange: Convert tokens between formats/scopes
• API Gateway validation: Centralized token validation

Mobile Application Authorization

• Use Authorization Code + PKCE
• Never store secrets in app code
• Utilize system browser for authorization steps

SPA (Single Page Application) Authorization

• Use Authorization Code + PKCE
• Store tokens in memory or secure HTTP-only cookies
• Implement token refresh patterns

Authorization Best Practices

Security Considerations

• Always use HTTPS for all endpoints
• Implement proper CORS policies
• Validate all redirect URIs
• Use short-lived access tokens
• Implement token revocation
• Never pass tokens in URL parameters
• Validate tokens on every request

Token Storage

Common Challenges and Solutions

OAuth 2.0 vs OAuth 2.1

OAuth Extensions and Related Protocols

• OpenID Connect: Identity layer on top of OAuth 2.0
• JWT (JSON Web Tokens): Token format with built-in validation
• Token Binding: Prevents token theft by binding to TLS layer
• OAuth 2.0 Token Exchange: Standard for exchanging tokens between services
• Device Authorization Grant: For devices with limited input capability
• Resource Indicators: Specifying target resources during authorization

Resources for Further Learning

• Specifications:

  • OAuth 2.0 RFC 6749
  • OAuth 2.1 Draft
  • OpenID Connect Core

• Community Resources:

  • OAuth.net
  • Auth0 Blog
  • IETF OAuth Working Group

• Tools:

  • JWT.io – Debug and inspect JWTs
  • OAuth.tools – OAuth testing playground
  • OpenID Connect Debugger

• Libraries:

  • Node.js: passport, oauth2-server
  • Java: Spring Security, Apache Oltu
  • Python: authlib, oauthlib
  • .NET: IdentityServer, Microsoft.Identity

Remember: No authorization system is perfect. Always implement defense in depth and stay updated on security best practices and vulnerabilities.