Oauth2 API Security
How Oauth2 Works in APIs
OAuth2 is the dominant authorization framework for APIs, enabling third-party applications to access user resources without exposing credentials. The flow typically involves an authorization server issuing access tokens to clients after user consent. These tokens are then presented to resource servers (APIs) to access protected endpoints.
The core security property of OAuth2 is token-based access control. When implemented correctly, tokens are short-lived, cryptographically signed, and scoped to specific permissions. The authorization server validates tokens and enforces access policies before granting API access.
Common OAuth2 flows include:
- Authorization Code: Web apps redirect users to authorization server, receive code, exchange for token
- Client Credentials: Machine-to-machine authentication using client secrets
- Implicit: Tokens returned directly in redirect (now deprecated)
- Resource Owner Password Credentials: Legacy flow using username/password
Each flow has specific security considerations. For instance, the Authorization Code flow with PKCE (Proof Key for Code Exchange) mitigates authorization code interception attacks, while Client Credentials flow requires secure secret storage and rotation.
Critical OAuth2 security properties include:
- Token confidentiality: Tokens must be protected in transit (HTTPS) and at rest
- Scope validation: APIs must verify token scopes match required permissions
- Audience validation: Tokens should be validated for the intended audience/API
- Expiration handling: Expired tokens must be rejected, refresh tokens rotated
MiddleBrick's OAuth2 security check validates these properties by testing token handling, scope enforcement, and endpoint protection without requiring your credentials.
Common Oauth2 Misconfigurations
Real-world OAuth2 implementations frequently contain critical vulnerabilities that expose APIs to unauthorized access. Here are the most common mistakes developers make:
Missing or Weak Audience Validation: Many APIs accept any valid JWT token without verifying the intended audience (aud claim). An attacker with a token for a different service can access your API if audience validation is missing. Example vulnerability:
// VULNERABLE - missing audience validation
const token = verifyJwt(tokenString); // accepts any valid token
// SECURE - validate audience
const token = verifyJwt(tokenString, { audience: 'https://api.yourservice.com' });Scope Bypass Through Case Sensitivity: OAuth2 scopes are case-sensitive, but many implementations mishandle this. An API requiring "read:profile" might accept "Read:Profile" or "read:PROFILE", granting unintended access. Attackers exploit this by trying variations of required scopes.
Token Leakage via URL Parameters: OAuth2 tokens should never be transmitted in URLs. Query parameters can be logged in server logs, browser history, and referer headers. Yet many implementations still pass tokens in redirect URLs:
// VULNERABLE - token in URL
const url = `https://api.example.com/data?access_token=${token}`;
// SECURE - use Authorization header
const url = 'https://api.example.com/data';
const headers = { 'Authorization': `Bearer ${token}` };Missing State Parameter in Authorization Code Flow: The state parameter prevents CSRF attacks during OAuth2 authorization. Without it, attackers can trick users into authorizing malicious applications. The state should be a cryptographically random value tied to the user's session.
Long-lived Access Tokens: Access tokens with expiration times exceeding 24 hours increase the attack window if compromised. Best practice is 15-60 minute lifetimes with refresh tokens for continued access.
MiddleBrick detects these misconfigurations by scanning your OAuth2 endpoints and testing for common validation bypasses, token handling issues, and scope enforcement problems.
Hardening Oauth2
Securing OAuth2 implementations requires defense-in-depth and adherence to best practices. Here's how to harden your OAuth2 deployment:
Implement Audience and Scope Validation: Always validate the audience claim matches your API identifier and verify requested scopes against required permissions. Use a library that enforces these validations by default:
from authlib.jose import jwt
def validate_token(token_string, required_scopes):
try:
token = jwt.decode(
token_string,
audience='https://api.yourcompany.com',
key=public_key
)
# Verify all required scopes are present
if not all(scope in token['scope'] for scope in required_scopes):
raise ValueError('Insufficient scopes')
return token
except Exception as e:
raise ValueError('Invalid token') from eEnforce PKCE for Public Clients: If your OAuth2 flow supports mobile or single-page applications, require PKCE (Proof Key for Code Exchange). This prevents authorization code interception attacks:
// Client generates code verifier and challenge
const codeVerifier = generateRandomString(128);
const codeChallenge = await sha256(codeVerifier);
// Authorization request includes challenge
const authUrl = `https://auth.example.com/authorize?
response_type=code&client_id=CLIENT_ID
code_challenge=${codeChallenge}&code_challenge_method=S256`;
// Server validates code and verifier match
app.post('/token', async (req, res) => {
const { code, code_verifier } = req.body;
const isValid = await verifyCodeChallenge(code, code_verifier);
if (!isValid) return res.status(400).json({ error: 'Invalid code challenge' });
});Implement Token Revocation and Rotation: Provide endpoints for clients to revoke tokens when users log out or when tokens are compromised. Rotate refresh tokens on each use to limit the impact of theft:
@PostMapping("/revoke")
public ResponseEntity revokeToken(@RequestBody RevokeRequest request) {
Token token = tokenRepository.findByToken(request.getToken());
if (token != null && tokenMatchesUser(token, request.getUserId())) {
token.setRevoked(true);
tokenRepository.save(token);
return ResponseEntity.ok().build();
}
return ResponseEntity.badRequest().build();
}Monitor and Rate Limit Token Endpoints: OAuth2 endpoints are prime targets for brute force and enumeration attacks. Implement rate limiting and monitor for suspicious patterns like repeated failed token validations or unusual token rotation frequency.
Regular Security Testing: Even with proper implementation, OAuth2 configurations can drift over time. Use automated scanning tools like middleBrick to continuously validate your OAuth2 security posture. MiddleBrick's OAuth2 check specifically tests for audience validation, scope enforcement, token leakage, and common misconfigurations without requiring access to your authorization server.
Remember that OAuth2 is an authorization framework, not authentication. For APIs requiring user identity, combine OAuth2 with OpenID Connect (OIDC) or implement additional user verification steps.
Frequently Asked Questions
Should I use JWT or opaque tokens for OAuth2?
Both have security trade-offs. JWT tokens are self-contained and reduce database lookups, but require careful validation and key management. Opaque tokens require server-side storage but are simpler to invalidate and rotate. For most APIs, JWT with proper validation (audience, scope, expiration) is recommended. If you need immediate revocation capability, opaque tokens with a fast lookup layer may be better.
How does middleBrick test OAuth2 security without credentials?
MiddleBrick uses black-box testing techniques to evaluate OAuth2 implementations. It tests publicly accessible OAuth2 endpoints by attempting token validation with malformed tokens, checking for audience and scope validation bypasses, testing token leakage via URLs, and verifying HTTPS enforcement. The scanner doesn't need your actual client secrets or user credentials—it tests the security properties of how your API handles and validates OAuth2 tokens.