API Security — OAuth, JWT, Rate Limiting

APIs (Application Programming Interfaces) are the backbone of modern applications, allowing services to communicate and share data. Securing APIs is about controlling access, ensuring data integrity, and preventing abuse. The SY0-701 exam focuses on three key mechanisms: OAuth 2.0 for delegated authorization, JWT for stateless token-based authentication/authorization, and rate limiting for protecting against brute-force and DoS attacks. Without these, APIs are vulnerable to unauthorized access, token theft, replay attacks, and resource exhaustion.

OAuth 2.0 (RFC 6749) is an authorization framework that enables third-party applications to obtain limited access to a user's resources without exposing the user's credentials. It is NOT an authentication protocol—though it is often misused as one. The core roles are: - Resource Owner: The user who owns the data (e.g., you). - Client: The application requesting access (e.g., a photo printing app). - Authorization Server: The server that issues tokens after authenticating the resource owner (e.g., Google's OAuth endpoint). - Resource Server: The server hosting the protected data (e.g., Google Photos API).

How It Works (Authorization Code Grant): 1. The client redirects the user to the authorization server with a request for access. The URL includes response_type=code, client_id, redirect_uri, and scope. 2. The user authenticates (e.g., logs into Google) and consents to the requested permissions. 3. The authorization server redirects back to the client with an authorization code in the query string. 4. The client sends this code to the authorization server's token endpoint (POST request with grant_type=authorization_code, code, client credentials) to receive an access token (and optionally a refresh token). 5. The client uses the access token to call the resource server's API, typically in the Authorization: Bearer <token> header.

Key Security Considerations: - The authorization code must be exchanged server-side to prevent interception (PKCE extension for public clients). - Access tokens should be short-lived (minutes to hours). Refresh tokens are long-lived and must be stored securely. - The redirect_uri must be validated to prevent open redirectors. - OAuth 2.0 does not define token format; JWT is commonly used for access tokens.

Common Grant Types (SY0-701 relevant): - Authorization Code: Most secure for server-side apps. - Implicit (legacy): No code exchange; token returned directly. Deprecated due to security issues (token in URL). - Client Credentials: For server-to-server communication; no user involvement. - Resource Owner Password Credentials: User gives password to client; high risk. Discouraged.

JWT (RFC 7519) is a compact, URL-safe token format used for transmitting claims between parties. It consists of three Base64url-encoded segments separated by dots: Header, Payload, Signature. Example:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.NHVaYe26MbtOYhSKkoKYdFVomg4i8ZJd8_-RU8VNbftc4gMbzFJk4xOEOQz6io1Hr0cZP1D1m0l6gYJcYg

How JWT Secures APIs: - Stateless: The server does not need to store session state; all info is in the token. - Integrity: Signature ensures the token has not been tampered with. - Claims can include user roles, permissions, and expiration.

Security Risks: - None Algorithm Attack: If the server accepts alg: none, an attacker can forge a token with no signature. Mitigation: Reject tokens with alg: none. - Key Confusion: Using a symmetric key as an asymmetric key (e.g., HS256 with RSA public key). Mitigation: Validate algorithm against expected list. - Token Theft: JWT in cookies or local storage can be stolen via XSS. Mitigation: Use HttpOnly cookies, short expiration, and refresh token rotation. - Replay: A stolen token can be reused until expiry. Mitigation: Use short expiry and implement token revocation (blacklist).

Rate limiting controls the number of requests a client can make to an API within a given time window. It protects against brute-force attacks, credential stuffing, and DoS.

Common Algorithms: - Token Bucket: Tokens are added at a fixed rate; each request consumes a token. Bursts are allowed up to bucket size. - Leaky Bucket: Requests are processed at a constant rate; excess requests are queued or dropped. - Fixed Window: Count requests per time window (e.g., 100 requests per minute). Vulnerable to burst at window boundaries. - Sliding Window: Uses a rolling time window to avoid boundary spikes.

Implementation: Rate limiting is often enforced at the API gateway or reverse proxy (e.g., Nginx, Kong, AWS API Gateway). Headers like X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After inform the client. When exceeded, the server returns HTTP 429 Too Many Requests.

Example Nginx Rate Limiting Config:

http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

This limits each IP to 10 requests per second, with a burst of 20.

Security Considerations: - Rate limiting should be applied per user (based on API key or token) as well as per IP to prevent one user from exhausting the limit of another (IP-based only can be circumvented via botnets). - Use exponential backoff for retries. - Rate limiting alone is not sufficient; combine with CAPTCHA or WAF for sophisticated attacks.