OWASP OAuth and JWT Security
Modern applications let users sign in with another account and let apps talk to each other through tokens. OAuth handles delegated access, and JSON Web Tokens, or JWTs, carry identity and permission claims. Both technologies work well when configured correctly and fail badly when teams skip details.
The Hotel Key Card Comparison
A hotel guest does not hand over the master key. The front desk issues a key card that opens one room for a limited time. OAuth follows the same principle: an app receives a limited token instead of the user's password.
OAuth Roles
| Role | Plain Meaning |
|---|---|
| Resource owner | The user who owns the data |
| Client | The app that wants access |
| Authorization server | The service that checks the user and issues tokens |
| Resource server | The API that holds the data |
Authorization Code Flow With PKCE
User → Client app: "Connect my account" Client → Authorization server: request + code challenge User ⇄ Authorization server: login and approve access Authorization server → Client: short-lived authorization code Client → Authorization server: code + code verifier Authorization server → Client: access token Client → Resource server: request with access token
PKCE adds a one-time secret to the exchange. A thief who steals the authorization code cannot trade it for a token without the verifier.
What a JWT Looks Like
xxxxx.yyyyy.zzzzz | | | Header Payload Signature
The header names the signing algorithm. The payload holds claims, such as the user ID, the issuer, the audience, and the expiry time. The signature proves that nobody changed the first two parts. Anyone can read the payload, so a JWT never carries secrets.
Frequent OAuth Mistakes
- Accepting loose redirect addresses, which lets attackers steer codes to their own pages. Register exact redirect URLs and compare them strictly.
- Skipping the state parameter, which opens the door to forged login requests.
- Using the old implicit flow that places tokens in URLs.
- Requesting more scopes than the app needs.
Frequent JWT Mistakes
| Mistake | Risk | Fix |
|---|---|---|
| Accepting the "none" algorithm | Unsigned tokens pass as valid | Allow a fixed list of algorithms |
| Weak signing secret | Attackers guess the secret and forge tokens | Use long random keys or asymmetric keys |
| No expiry claim | Stolen tokens work forever | Set short lifetimes |
| Ignoring issuer and audience | Tokens for another service work here | Verify both claims |
| Sensitive data in payload | Anyone can decode and read it | Store only identifiers and permissions |
Safe Verification Steps
- Verify the signature with the expected algorithm and key.
- Check the expiry and not-before times.
- Match the issuer and audience to your own values.
- Confirm the scopes cover the requested action.
- Check a revocation list when the application needs instant logout.
Token Storage and Lifetime
Access tokens should live for minutes. Refresh tokens live longer and need stronger protection, such as rotation on every use and detection of reuse. Browser applications benefit from HttpOnly cookies, while server-side apps can keep tokens in protected memory or encrypted storage.
Key Takeaways
- OAuth delegates limited access without sharing passwords.
- PKCE and exact redirect URLs protect the authorization code.
- A JWT proves integrity, not secrecy.
- Strict verification of algorithm, signature, expiry, issuer, and audience keeps tokens trustworthy.