OAuth 2.0 Threat Model

This threat occurs when an attacker steals the authorization code as it is transmitted from the authorization server back to the client, typically via the browser's redirect URI. The attacker can then exchange this intercepted code for an access token.

Primary Countermeasure: Proof Key for Code Exchange (PKCE). The client creates a cryptographically random code_verifier and sends a derived code_challenge with the initial authorization request. The original code_verifier must be presented when exchanging the code for a token, binding the token issuance to the original requestor.

Bearer tokens can be leaked from client storage, browser history, logs, or network traffic. Any party in possession of a valid token can use it to access protected resources until it expires.

Key Countermeasures:

• Short-Lived Access Tokens: Minimize the usable window after a leak.
• Token Binding: Associate the token with a specific client characteristic (e.g., a TLS certificate via mTLS or a DPoP proof).
• Confidential Clients: Store tokens securely on a backend server, not in public clients like mobile apps or SPAs.
• Token Introspection: Resource servers should validate token status with the authorization server.

An attacker registers a malicious client that mimics a legitimate one or steals a legitimate client's credentials (client ID and secret). This allows the attacker to obtain tokens as if they were the trusted application.

Key Countermeasures:

• Strong Client Authentication: Move beyond simple client secrets to private_key_jwt or mTLS-based client authentication.
• Redirect URI Validation: Authorization servers must strictly validate registered redirect URIs to prevent tokens from being delivered to attacker-controlled endpoints.
• Dynamic Client Registration Management: Scrutinize and audit client registrations.

A resource server fails to properly validate the scopes associated with an access token, granting the client more access than was authorized by the user. For example, a token with read scope might be accepted for a write operation.

Primary Countermeasure: Resource servers must implement strict scope checking for every API endpoint. The authorization server must include the granted scopes in the token (e.g., in a JWT scope claim) or make them available via token introspection. The resource server's policy engine must enforce these scopes.

Attackers trick users into authorizing a malicious OAuth client, often by mimicking the login page of a trusted service (phishing) or by obscuring the true scope of permissions being requested during the consent dialog.

Key Countermeasures:

• User Education: Train users to verify the requesting application's identity and the permissions list.
• Customizable Consent Screens: Clearly list the specific data and actions the client will access.
• Client Identity Assurance: Use certifications (e.g., FAPI conformance) to signal high-assurance clients.

In the Implicit Grant flow (now discouraged), the access token is returned in the URI fragment of the redirect. While fragments are not sent to the server, they may be leaked through browser history, referrer headers, or logging plugins.

Primary Countermeasure: Deprecate the Implicit Flow. Use the Authorization Code Flow with PKCE for all browser-based applications (SPAs, mobile apps). This flow returns only a short-lived code to the browser, and the token is retrieved via a secure backend channel or a client-constrained frontchannel.

While RFC 6819 covers traditional OAuth clients, Agentic Threat Modeling extends this discipline to the unique risks posed by autonomous AI agents executing API calls. It analyzes threats specific to the tool-calling paradigm:

• Prompt Injection for Credential Theft: Manipulating an agent to exfiltrate OAuth tokens or secrets.
• Unintended Cascading Authorization: An agent using one access token to create another with broader scope.
• Orchestration Layer Vulnerabilities: Attacks on the middleware that manages the agent's tool calls and token lifecycle.
• Non-Human Token Usage Patterns: Detecting anomalies when tokens are used by AI agents instead of human-driven applications.