1. OAuth Security Overview

OAuth is a widely used authorization framework that enables secure access delegation for web, mobile, and desktop applications without sharing credentials.

1.1 OAuth Workflow

graph LR
    A[Resource Owner/User] -->|Authorize| B[Authorization Server]
    B -->|Authorization code| C[Client callback]
    C -->|Code + PKCE verifier| E[Token endpoint]
    E -->|Access token| C
    C -->|Request Resource| D[Resource Server]
    D -->|Provide Resource| C

Key Entities in OAuth:

1. Resource Owner (User): Grants access to their data.
2. Client (App): Requests access to user data.
3. Authorization Server: Issues access tokens.
4. Resource Server: Hosts protected resources.

2. OAuth Flows and Security Considerations

2.1 Authorization Code Grant vs. Implicit Grant

✅ Mitigation: Avoid Implicit Grant in modern applications due to its security risks.

2.2 OAuth Attack Vectors & Exploits

Attackers commonly exploit OAuth misconfigurations in redirect URIs, token storage, or validation processes.

2.2.1 Redirect URI Manipulation (Access Token Theft)

Improper validation of the redirect_uri parameter allows an attacker to intercept access tokens.

Attack Steps

1. Victim clicks a crafted authorization request with a malicious redirect URI:

http://hubgit.htb/authorization/auth?response_type=code&client_id=0e8f12335b0bf225&redirect_uri=http://attacker.htb/callback&state=somevalue

2. With response_type=code, the authorization server redirects with an authorization code, not an access token.
3. A vulnerable redirect policy can disclose the code; PKCE and exact redirect URI matching limit whether it can be redeemed.

✅ Mitigation:

• Strict URI validation: Use exact matching instead of wildcard matching (*.domain.com).
• Use PKCE (Proof Key for Code Exchange) to prevent token theft.

2.2.2 CSRF in OAuth Flow (Login CSRF)

OAuth uses the state parameter to prevent Cross-Site Request Forgery (CSRF).

Attack Scenario

1. Attacker prepares an OAuth login request with a valid code but without a state parameter.
2. Victim unknowingly clicks the crafted link, logging them into the attacker's account.
3. The victim may be logged into the client under the attacker's account, producing login CSRF or account confusion rather than necessarily hijacking the victim's session.

✅ Mitigation:

• Enforce the state parameter in OAuth requests.
• Use a cryptographically secure state value (e.g., a random nonce).

2.2.3 Token Reuse & Token Replay Attacks

OAuth tokens without expiration can be stolen and reused indefinitely.

Attack Scenario

1. Attacker steals a valid access token from session storage.
2. The attacker reuses the token to impersonate the victim.

✅ Mitigation:

• Use short-lived access tokens with refresh tokens.
• Implement token revocation mechanisms.

2.2.4 Weak JWT Token Signature Verification

OAuth access tokens may be opaque or structured; some deployments use JWTs. If a JWT access token is used, its verifier must apply the expected issuer, audience, algorithm, key, type, and lifetime policy.

• Change the alg to none (Algorithm Confusion Attack).
• Brute-force weak HS256 secrets.

Attack Example

Modify JWT Header:

{
  "alg": "none",
  "typ": "JWT"
}

Use a token without a signature:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

✅ Mitigation:

• Enforce RS256 over HS256.
• Reject none algorithm.

2.2.5 OAuth Open Redirect Exploitation

If a service allows open redirects, attackers can chain them with OAuth flows.

Attack Example

Attacker exploits an open redirect:

http://hubgit.htb/redirect?target=http://attacker.htb

OAuth authentication redirects the victim via the open redirect, exposing the token.

✅ Mitigation:

• Block open redirects.
• Use a strict allowlist for redirect URIs.

2.2.6 Malicious OAuth Clients

Attackers may register a malicious OAuth client and request excessive consent. This differs from operating a fake authorization server.

Attack Steps

1. A user is induced to authorize a malicious registered client.
2. The authorization server issues only the scopes the user or policy permits.
3. Excessive consent can expose API access until the grant is revoked.

✅ Mitigation:

• Use Trusted OAuth Providers Only.
• Enforce client registration review processes.

3. OAuth Security Best Practices

4. Exploit & Lab Setup

graph TD
    A[User] -->|Log in with HubGit| B[Authorization Server]
    B -->|Access Token| C[OAuth Client: academy.htb]
    C -->|Request User Data| D[Resource Server: hubgit.htb]
    D -->|Provide User Data| C

Validation 1: Redirect URI rejection

Use a local authorization-server fixture, synthetic client, and non-secret code. Confirm that an unregistered redirect URI is rejected and logged.

# Capture OAuth Authorization Request
https://auth.lab.invalid/authorize?response_type=code&client_id=synthetic-client&redirect_uri=https://unregistered.lab.invalid/callback

✅ Mitigation:

• Enforce exact redirect URI validation.
• Use a strict allowlist.

Validation 2: JWT access-token verifier policy

If the local fixture issues JWT access tokens, submit a synthetic token signed by an untrusted lab key and confirm the resource server rejects it and logs the reason. Do not crack or collect credentials.

✅ Mitigation:

• Configure an explicit algorithm and issuer/key binding appropriate to the architecture.
• Rotate keys safely and verify rejection of retired or untrusted keys.

5. OAuth Vulnerabilities Table