OAuth 2.0 — How the Authorization Framework Works in Modern Applications

What is OAuth 2.0?

OAuth 2.0 is an authorization framework^?authorization framework: a flexible set of rules and mechanisms for delegating access — it does not impose a single rigid implementation, which enables broad adoption but requires deliberate design defined in RFC 6749 by the Internet Engineering Task Force (IETF). Its core purpose is to enable the secure delegation of access permissions to resources — without requiring users to share their passwords with third-party applications.

The standard is intentionally described as a "framework" rather than a protocol. This means it provides general structures and mechanisms that can be implemented in different ways. This flexibility drove its mass adoption but also created space for implementation mistakes.

Who is behind it?

OAuth 2.0 was developed under the auspices of the IETF. The primary author and editor of RFC 6749 was Dick Hardt, a digital identity expert. The previous version, OAuth 1.0, required signing every HTTP request using complex cryptographic algorithms (HMAC-SHA1, RSA) — which was difficult to implement correctly. OAuth 2.0 shifted cryptographic responsibility to the TLS/HTTPS transport layer, dramatically simplifying client integrations.

Today the standard is maintained by the IETF OAuth Working Group, which is actively developing OAuth 2.1 — a consolidation of all security fixes that removes deprecated mechanisms from the specification.

How does it work?

OAuth 2.0 defines four distinct roles:

• Resource Owner — typically the end user — owns the data and can grant access to it.
• Client — the application requesting access to protected resources.
• Authorization Server — authenticates the Resource Owner, collects consent, and issues tokens.
• Resource Server — the API or data store holding the protected resources. Verifies access tokens and serves data based on them.

Authorization Code Flow

Example: you log in to Spotify using your Google account.

1. You click "Continue with Google" on Spotify's login page. Spotify redirects your browser to Google with: client_id=spotify, scope=email profile, redirect_uri=https://accounts.spotify.com/callback, state=xyz789.
2. On Google's page you log in and approve the consent screen: "Spotify wants access to your name and email address". You click Allow.
3. Google redirects your browser back to Spotify with a one-time authorization code embedded in the URL: https://accounts.spotify.com/callback?code=SplxlOBeZQ…&state=xyz789. The code alone grants no access — Spotify's secret key is still required.
4. Spotify's server — without your browser's involvement (back-channel) — sends the code and client_secret to Google. In return it receives an Access Token and Refresh Token in JSON.
5. The token stays on Spotify's server — your browser never sees it. You receive a session cookie (HttpOnly) and land on your Spotify account, logged in.
6. When Spotify needs your data (e.g., your name to display in the profile), its server sends a request to the Google API with the Authorization: Bearer <token> header. Google verifies the token and returns the data.

PKCE Extension

PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — a cryptographic extension to the Authorization Code Flow that binds the authorization request to the code exchange, preventing code interception attacks adds a critical protection layer. Before initiating the flow, the client generates a random code_verifier, hashes it with SHA-256^?SHA-256: A cryptographic hash function from the SHA-2 family. For any input it produces a fixed-length 256-bit digest. Even a minimal change in the input results in a completely different output. Widely used in HTTPS, digital signatures, and OAuth 2.0. as a code_challenge, and sends it with the authorization request. When exchanging the code for a token, the server verifies that the submitted code_verifier matches the stored challenge — ensuring only the original client can complete the exchange.

Below is an overview of the main grant types and their current status:

What are its key components?

Beyond the four roles, tokens are the fundamental building blocks of OAuth 2.0.

Access Token

An Access Token is a short-lived credential (typically 5–15 minutes) sent in the HTTP header with every API request. It comes in two formats. An Opaque Token is a random string with no embedded meaning — the Resource Server must contact the Authorization Server's introspection endpoint to verify it. A JSON Web Token (JWT) is a self-contained, cryptographically signed token with a payload containing claims^?claims: a set of assertions embedded in a JWT describing the subject's identity and authorization context — including sub (user identifier), iss (issuer), aud (intended audience), exp (expiration), and scope (granted permissions). JWTs enable local, stateless verification without contacting the Authorization Server.

Refresh Token

A Refresh Token is a long-lived credential (e.g., 7–30 days) used to silently obtain new Access Tokens after expiry — without requiring the user to log in again. Refresh Token Rotation invalidates each token after use and issues a new one, protecting against Replay Attacks.

Scope

Scope^?Scope: the defined set of permissions granted to the client — e.g., "read:calendar" grants only calendar read access, not the rest of the account defines the boundaries of granted access. Fine-grained, well-designed scopes minimize risk — the application receives access only to what it genuinely needs.

What can it be used for?

OAuth 2.0 powers the majority of delegated access scenarios on the modern web:

• Federated login — "Sign in with Google / GitHub / Facebook" buttons on external services. The user authenticates with their identity provider, and the external app receives a scoped token.
• Machine-to-Machine (M2M) — backend service communication without user involvement (Client Credentials Flow^?Client Credentials Flow: An OAuth 2.0 flow for Machine-to-Machine (M2M) communication. The client (a service) authenticates directly with the Authorization Server using its own client_id and client_secret — no user involved. Used in microservices and automated pipelines.). A service authenticates with its own client_id and client_secret.
• Single Sign-On (SSO) in enterprise environments — one login granting access to CRM^?CRM: Customer Relationship Management — software for managing customer interactions, contact history, contracts, sales data, and all communications with clients., email, and developer environments, combined with OpenID Connect.
• Devices without full input — IoT devices, Smart TVs, and CLIs use Device Authorization Flow: the device displays a short code and the user authorizes access from their phone.

How does it differ from other approaches?

The main competitor to OAuth 2.0 in enterprise environments is SAML 2.0^?SAML 2.0: Security Assertion Markup Language — an XML-based identity federation protocol widely used in enterprise environments for Single Sign-On. It exchanges authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP) in XML format.. SAML is XML-based and deeply embedded in legacy enterprise infrastructure (Active Directory Federation Services^?Active Directory Federation Services: A Microsoft service (ADFS) that enables Single Sign-On between applications within a corporate network and external services. It acts as an Identity Provider (IdP) and communicates via the SAML 2.0 protocol.). OAuth 2.0 uses the lighter-weight JSON format and is better suited for mobile apps and API-first^?API-first: A software design approach in which the API is treated as the primary product from day one. Interfaces are designed and documented before implementation, making integration and scaling significantly easier. architectures. Many organizations use both in parallel — an Authorization Server can broker between OAuth 2.0 applications and legacy systems that speak SAML.

OAuth 1.0^?OAuth 1.0: The previous version of the OAuth standard (RFC 5849), requiring cryptographic signing of every HTTP request. Incompatible with OAuth 2.0, superseded due to implementation complexity and poor support for mobile environments. required signing every HTTP request with HMAC^?HMAC: Hash-based Message Authentication Code — a mechanism for verifying message integrity that combines a hash function (e.g., SHA-256) with a secret key. It guarantees that a message has not been modified and originates from an authorized sender. or RSA^?RSA: An asymmetric cryptographic algorithm based on the difficulty of factoring the product of large prime numbers. Uses a key pair: a public key (for encryption and signature verification) and a private key (for decryption and signing). algorithms and precise URL parameter sorting — error-prone and difficult to implement. OAuth 2.0 delegates cryptographic security to the transport layer (HTTPS^?HTTPS: HTTP over TLS — the encrypted version of HTTP. Provides confidentiality (data cannot be intercepted), integrity (data cannot be modified in transit), and server authentication via an SSL/TLS certificate./TLS^?TLS: Transport Layer Security — a cryptographic protocol ensuring secure communication over a network. The successor to SSL. Encrypts the connection between client and server, protecting data in transit.), simplifying integration.

Key limitations and challenges

OAuth 2.0 is a flexible framework, not a strict protocol — and that very flexibility is the source of its greatest weaknesses. Here are five real limitations worth knowing when designing authorization systems.

• Flexibility without enforced rules — RFC 6749 does not define token formats, specific endpoints, or mandatory behaviors. Every provider implements the standard differently. This eases adoption but produces inconsistent implementations and pitfalls for developers switching between identity providers.
• Authorization only — not authentication — OAuth 2.0 does not verify a user's identity. Using an Access Token directly as proof of "Who are you?" is a common mistake that leads to security vulnerabilities. Authentication requires a separate protocol — OpenID Connect (OIDC^?OIDC: OpenID Connect — an authentication protocol built on top of OAuth 2.0. It answers "Who are you?" — after login it issues an ID Token (JWT) containing user data (name, email). OAuth 2.0 alone does not provide authentication.).
• Full dependency on TLS — the entire OAuth 2.0 security model rests on the transport layer. Misconfigured TLS (outdated versions, weak ciphers, missing certificate validation) undermines all protection regardless of how correctly OAuth itself is implemented.
• JWT revocation problem — JWT tokens are stateless and self-contained: the Resource Server verifies them locally without contacting the Authorization Server. This is a performance advantage, but makes immediate revocation impossible. The only reliable solution is a server-side blocklist^?server-side blocklist: A server-maintained list of revoked tokens. On every request the server checks whether the token has been invalidated. Effective, but requires server-side state — which negates the statelessness benefit of JWT tokens. — which negates the statelessness benefit.
• Ecosystem fragmentation — Google, GitHub, Microsoft Entra ID, and Auth0 implement OAuth 2.0 differently: varying endpoint names, different scope conventions, specific token refresh behaviors. Integrating with multiple identity providers requires handling their specifics, not just knowledge of RFC 6749.

Security threats and attacks

Even a correctly designed OAuth 2.0 system can fall victim to implementation mistakes or deliberate attacks. Below we describe two of the most common attacks targeting the authorization layer, along with a set of practices that effectively neutralize them.

JWT Algorithm Confusion (Key Confusion)

An attacker modifies the signature algorithm in the JWT header from RS256 (asymmetric) to HS256 (symmetric), then uses the publicly available server public key as a symmetric secret to forge a token. A poorly configured library on the Resource Server may accept such a token. Remedy: explicitly and statically configure the accepted verification algorithm on the server side — never trust the alg field in a received token's header.

BOLA (Broken Object Level Authorization)

An attacker holds a legitimate token for account A but queries an endpoint for account B's data (e.g., /api/users/12345). If the server only checks "is the token valid?" without verifying "does this token belong to the owner of this resource?", a mass data breach becomes trivial. Remedy: contextual resource authorization — verify that the sub claim in the JWT matches the owner of the requested object.

Security best practices

• Use only modern flows (Authorization Code + PKCE). Implicit Flow and ROPC are officially removed in OAuth 2.1.
• Always validate iss, aud, and exp when verifying any JWT.
• Store tokens in HttpOnly/Secure/SameSite cookies — not in localStorage (vulnerable to XSS^?XSS: Cross-Site Scripting — an attack in which malicious JavaScript is injected into a web page. The script runs in the victim's browser and can read data from localStorage, sessionStorage, or cookies that lack the HttpOnly flag. theft).
• Maintain a strict whitelist of redirect_uri values — no wildcard patterns.

OAuth 2.0 in the Age of AI Agents

The growing adoption of AI agents, large language models, and integration platforms has given OAuth 2.0 an unexpected new domain: it is now the protocol that enables AI to act on behalf of humans — securely and with permissions that can be revoked at any time.

AI APIs and Bearer Tokens

Most commercial AI model APIs — OpenAI, Anthropic, Google — do not require the full OAuth 2.0 flow. Access to their endpoints is handled via a static API key sent as a Bearer token in the Authorization header. The architecture, however, directly mirrors OAuth 2.0: a Bearer token in the header, the ability to scope permissions, short token lifetimes for session credentials.

OAuth 2.0 in full form appears where an AI agent needs access to a specific user's data: reading Gmail, modifying files in Google Drive, retrieving records from Salesforce, or calling the GitHub API. In such scenarios — common in RAG pipelines and agent orchestration systems — Authorization Code Flow with PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — a cryptographic extension to the Authorization Code Flow. The client generates a random code_verifier and its hash (code_challenge). The server verifies them when exchanging the code for a token, ensuring only the original client can complete the exchange. is the only architecturally correct option.

AI Agents, Delegation, and the Consent Problem

An autonomous AI agent that needs to book a meeting, read an inbox, or generate an invoice must act on behalf of the user. This is a classic permission delegation scenario — exactly the use case OAuth 2.0 was designed for. In practice, AI agents use two primary flows:

• Authorization Code + PKCE — the agent acts on behalf of a specific user. Example: an AI assistant in a CRM^?CRM: Customer Relationship Management — software for managing customer interactions, contact history, contracts, sales data, and all communications with clients. that reads customer data after the employee grants consent through a standard OAuth consent screen.
• Client Credentials Flow — the agent acts on behalf of the entire organization, not a specific person. Example: an analytics pipeline pulling nightly reports from an ERP^?ERP: Enterprise Resource Planning — integrated software managing a company's core processes: finance, accounting, inventory, production, procurement, and HR. Examples: SAP, Oracle ERP, Microsoft Dynamics. system without user involvement.

The challenge emerges with long-running agentic tasks. The Access Token expires after a few minutes, and the user may no longer be available to log in again. Refresh Tokens with rotation or a Backend-for-Frontend architecture — where the agent uses session tokens managed server-side, out of reach of the browser and malicious scripts — solve this.

Model Context Protocol and OAuth 2.0

Anthropic's Model Context Protocol (MCP) — the emerging standard for communication between AI agents and external tools and services — explicitly designates OAuth 2.0 as the authorization mechanism for MCP servers. When an AI agent connected via MCP wants to call a tool requiring user permissions (e.g., reading a Spotify playlist or modifying a Google Docs file), the MCP server initiates a standard OAuth 2.0 flow.

The agent then operates with scoped, revocable permissions — not a full-access static API key. The user can withdraw consent at any time through the identity provider's dashboard, immediately preventing the agent from continuing. This pattern — AI as an OAuth client — has become the de facto standard in the agentic integration ecosystem.

Security Challenges in Multi-Agent Chains

Multi-agent architectures introduce new classes of problems for OAuth 2.0. When Agent A delegates a task to Agent B, which in turn calls Agent C — who holds the token? What scope is forwarded down the chain? Can Agent C operate with the user's full permissions, or only the subset that Agent A originally received?

Industry proposals such as Token Exchange^?Token Exchange: RFC 8693 — an OAuth 2.0 token exchange mechanism that allows an agent to obtain a token with a narrowed permission scope based on an existing parent token (RFC 8693) allow agents to exchange tokens down the chain with a mandated scope reduction. Without this mechanism, scope creep becomes a real risk: an agent with calendar read permissions may inadvertently — or maliciously — operate in scopes the user never approved.

Will OAuth 2.0 Be Replaced?

OAuth 2.0 is over a decade old, and the world of AI and distributed architectures has changed dramatically since its standardization in 2012. Does it face obsolescence?

GNAP^?GNAP: Grant Negotiation and Authorization Protocol (RFC 9635) — an authorization protocol designed as a successor to OAuth 2.0, with native support for complex delegation scenarios and serverless clients (Grant Negotiation and Authorization Protocol, RFC 9635) is the most serious replacement candidate. Designed for more complex delegation scenarios — multi-step negotiations, native support for serverless clients, and cleaner role separation — GNAP has an elegant architecture. As of 2025, however, its production adoption is near zero: none of the major identity providers (Okta, Auth0, Microsoft Entra ID, Google) yet offer full support.

OAuth 2.1 is the more likely "successor" — the same protocol family, consolidating a decade of security patches without breaking architectural changes. Extensions such as DPoP^?DPoP: Demonstrating Proof of Possession (RFC 9449) — an OAuth 2.0 extension that binds an access token to a specific client cryptographic key. Even if the token is stolen, an attacker cannot use it without the client's private key. (Demonstrating Proof of Possession, RFC 9449) and PAR^?PAR: Pushed Authorization Requests (RFC 9126) — an OAuth 2.0 extension in which the client sends authorization request parameters directly to the server (back-channel) instead of through the browser URL. Eliminates the risk of front-channel parameter tampering. (Pushed Authorization Requests, RFC 9126) strengthen OAuth 2.0 specifically for AI agents and headless environments.

In the AI context: OAuth 2.0 is not only unlikely to be displaced soon — it is reinforcing its position as the permissions foundation for agentic architectures. Every platform integrating AI with user data while caring about security returns to the same primitives: Authorization Server, scoped permissions, short-lived tokens, the ability to revoke.

It is no coincidence that MCP, OpenAI Custom Actions, Microsoft Copilot Extensions, and Google Workspace Actions all designate OAuth 2.0 as the default authorization mechanism. The 2012 protocol has proven flexible enough to become the foundation of the AI agent era.

Why does it matter?

OAuth 2.0 has become the foundational infrastructure layer for identity and authorization on the modern internet. Every "Sign in with Google" button, every third-party service integrating with your data, every service-to-service call in a cloud-native microservices architecture — all of it runs on this standard or on layers built directly on top of it.

The upcoming OAuth 2.1 specification consolidates a decade of security patches into a single document: PKCE becomes mandatory for all client types, Implicit Flow and ROPC are removed, and what were previously "best practices" become normative requirements. For anyone designing authentication and authorization systems, understanding OAuth 2.0 — not as a copy-paste script, but as a deliberate architecture for delegating trust — is foundational to building secure software.

It is worth remembering that the protocol itself is only a tool. Implementation mistakes — improper JWT claims validation, absent resource-level authorization checks, use of deprecated flows — can undermine security even in the most carefully designed system. A solid understanding of OAuth 2.0 mechanics is the shield against the most common attack vectors targeting authorization layers.

Sources

• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• IETF — RFC 7636: Proof Key for Code Exchange — link
• Auth0 / Okta — OAuth 2.0 documentation — link
• OAuth.net — Official OAuth 2.0 resource — link
• IETF — OAuth 2.0 Security Best Current Practice (RFC 9700) — link
• IETF — RFC 8693: OAuth 2.0 Token Exchange — link
• IETF — RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) — link
• IETF — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — link
• IETF — RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — link
• OAuth.net — OAuth 2.1 (draft specification) — link
• IETF OAuth Working Group — working repository — link