OAuth

What is OAuth 2.0

OAuth 2.0 (RFC 6749) is an authorization framework that lets a user grant a third-party application limited access to their resources without sharing credentials. OAuth defines four roles:

• Resource Owner — the user who owns the data
• Client — the application requesting access on behalf of the user
• Authorization Server — issues tokens after authentication and consent
• Resource Server — hosts the protected resources and validates tokens

Access Token and ID Token

• An ID Token (from OpenID Connect) contains claims about the end user, such as email address, username, etc.
• An Access Token allows access to certain defined server resources.
• Don’t use an ID token for authorization — you must NOT use an ID token to call an API.

Access Token and Refresh Token

• For security purposes, access tokens are usually valid for a short amount of time.
• A refresh token is a long-lived credential that can be exchanged for a new access token when the current one expires, without asking the user to sign in again.
• Refresh tokens should be stored securely (server-side) and can be revoked by the authorization server.

Authorization Code Flow (simplified)

1. The client redirects the user to the authorization server (/authorize?response_type=code&client_id=...&redirect_uri=...).
2. The user authenticates and grants consent.
3. The authorization server redirects back with an authorization code.
4. The client exchanges the code (plus its own credentials) at the token endpoint for an access token (and optionally a refresh token).

The authorization code never goes through the browser on the final exchange — only the client sees the token.

Common OAuth Vulnerabilities and Protections

1. Missing or weak state (CSRF)

Without a state parameter binding the request to the user’s session, an attacker can force a victim into a session the attacker started (login CSRF).

Fix: always generate a random, unguessable state and verify it on the redirect back.

2. redirect_uri manipulation

If the authorization server does not strictly validate redirect_uri, an attacker can use an open redirector or a client-controlled URI to steal the authorization code.

Fix: register exact redirect URIs per client and match them exactly.

3. Missing PKCE

In the code flow, an attacker who obtains the authorization code (e.g. via a compromised redirect) could exchange it. PKCE (RFC 7636) binds the code to the client with a code_challenge (SHA-256 of a code_verifier) and code_verifier.

Fix: use PKCE (code_challenge / code_verifier) even for confidential clients, to protect the code exchange.

Security notes

• Always use the state parameter to prevent CSRF on the redirect.
• Use PKCE (code_challenge / code_verifier) even for confidential clients, to protect the code exchange.
• Never log tokens, and keep them out of URLs.
• Validate aud and iss claims if tokens are JWTs.

Summary

OAuth is a protocol about delegation — the security depends on the details: strict redirect_uri registration, state for CSRF protection, and PKCE to bind the code exchange. Small implementation mistakes turn into token theft and account takeover.