Modern OAuth 2.0 Security
OAuth 2.0 has evolved significantly since its original specification. Modern best practices address many of the original protocol's security weaknesses through extensions like PKCE, DPoP, and the deprecation of implicit flow.
Critical Security Patterns
Authorization Code + PKCE (Mandatory)
PKCE prevents authorization code interception:1. Client generates code_verifier (random string)
2. Client sends code_challenge = SHA256(code_verifier)
3. Server stores code_challenge with the authorization code
4. Client exchanges code + code_verifier
5. Server verifies SHA256(code_verifier) == stored challenge
Use PKCE for ALL clients, not just public clients.
DPoP (Demonstrating Proof of Possession)
Bind access tokens to the client's key pair:DPoP: eyJ... (JWT signed with client's private key)
Authorization: DPoP eyJ... (DPoP-bound access token)
Even if the token is stolen, it can't be used without the private key.
Sender-Constrained Tokens
Certificate-bound tokens using mTLS:Token bound to client certificate thumbprint
Different client certificate = token rejected
Deprecated Patterns
Implicit Flow (NEVER Use)
- Tokens in URL fragments
- Exposed in browser history
- No refresh tokens
- Replace with Authorization Code + PKCE
Resource Owner Password Credentials (NEVER Use)
- Client handles user passwords directly
- No IdP involvement
- Blocks MFA adoption
- Replace with Authorization Code flow
Best Practices Checklist
- Use Authorization Code + PKCE for all flows
- Implement exact redirect URI matching
- Validate state parameter for CSRF protection
- Use short-lived access tokens (5-15 minutes)
- Rotate refresh tokens on each use
- Implement token revocation endpoint
- Restrict token scopes to minimum needed
SuperClue OAuth Module
SuperClue's OAuth module probes the OAuth endpoints it finds on your site and tests redirect URI manipulation. It is a starting point, not a full review of PKCE, deprecated flows, and token handling.