OAuth 2.0 Guide - Authorization Flows Explained

Delegated Authority at Scale

OAuth 2.0 is the architectural foundation of modern web and mobile security. It is not an identity protocol, but an Authorization Framework designed to solve a single, critical problem: how to grant a third-party application limited access to a user’s data without revealing the user’s password. By introducing a “Delegation Layer” between the user and the service, OAuth 2.0 allows for the issuance of short-lived, scope-limited “Access Tokens.” This framework powers everything from “Sign in with Google” to the interconnected microservices of the world’s largest cloud platforms.

OAUTH

Authorization Framework

Core Mission

Delegated Authorization. Securely granting restricted access to protected resources across independent service boundaries.

Like a Universal Valet Key: When you give your car to a valet, you don't give them your master key (The Password) which opens the trunk and glovebox. You give them a Valet Key (The Access Token). It allows them to drive the car for a limited distance and park it, but it restricts them from accessing your private belongings. It is a temporary, limited-authority version of your primary access.

API Delegation / Mobile App Backends / Machine-to-Machine Auth

The OAuth 2.0 Ecosystem

Efficient OAuth design requires a deep understanding of the interactions between four distinct architectural roles.

Structural Roles & Responsibilities

Role	Entity	Strategic Responsibility
Resource Owner	The User.	The entity capable of granting access to a protected resource.
Client	The Application.	The software requesting access (Web, Mobile, or Service).
Resource Server	The API.	The server hosting the user’s data, which accepts Access Tokens.
Auth Server	The IdP.	The trusted engine that authenticates the user and issues tokens.

The Delegation Journey

While there are many flows (Grants), the “Authorization Code Flow” is the gold standard for secure delegation.

sequenceDiagram
    participant User
    participant Client as Application
    participant Auth as Auth Server
    participant API as Resource API
    
    User->>Client: "Connect my Data"
    Client->>Auth: Redirect to Authorize
    Auth->>User: Request Consent
    User-->>Auth: I Approve
    Auth-->>Client: Delivery Auth Code
    Client->>Auth: Exchange Code + Secret
    Auth-->>Client: Issue Access Token
    Client->>API: Request Data (with Token)
    API-->>Client: Delivers Resource

1

Redirect & Consent

The Client redirects the user to the Auth Server. The user authenticates and explicitly approves the requested permissions (Scopes), ensuring the Client never sees the user's credentials.

2

Secure Exchange

The Auth Server delivers a temporary "Authorization Code" to the client. The client then performs a back-channel exchange, swapping the code for a cryptographically signed "Access Token."

3

Access & Access

The Client presents the Access Token to the Resource API. The API validates the token's scope and integrity before delivering the requested data, completing the chain of trust.

---

Strategic Flow Selection

Choosing the correct grant type is critical for maintaining an acceptable security posture for your application type.

Grant Type Matrix

Flow	Client Type	Security Profile	Status
Authorization Code	Server-side Web.	Highest (Secret-based).	Recommended.
Code + PKCE	SPAs & Mobile.	High (Challenge-based).	Mandatory for Public.
Client Credentials	Backend Services.	High (M2M).	Recommended.
Implicit	Legacy SPAs.	Low (Token in URL).	Deprecated.

⚠️ Security Warning: Implicit Flow Deprecation

The OAuth 2.0 Implicit Flow is officially deprecated for modern applications. It is susceptible to token leakage via browser history and referral headers. All modern Single Page Applications (SPAs) and Mobile Apps must use the Authorization Code Flow + PKCE (Proof Key for Code Exchange) to ensure a secure machine-to-machine handshake without exposing tokens in the URI.

OAuth Implementation Guides

Master the technical details of high-assurance delegation.

PKCE Extension

Mandatory security for public clients and mobile applications.

Scope Design

Strategic principles for designing granular and maintainable API authorities.

Security Hardening

Defenses against injection, token leakage, and replay attacks.

Token Lifecycle

Best practices for storage, rotation, and cryptographic validation.

Next Steps

• Transition to OpenID Connect (OIDC) for identity and user profile retrieval.
• Review JWT Security Best Practices for validating and parsing bearer tokens.
• Explore API Gateway Integration for centralizing token enforcement.