API Security: JWT and OAuth 2.0 Implementation Mistakes
JWT and OAuth 2.0 in API security: signature validation mistakes, algorithm confusion, token lifetimes and refresh rotation, PKCE and scope discipline — an implementation guide.
Is JWT secure?
JWT is secure as a format; what is insecure is the set of common implementation mistakes. Nearly every major JWT incident in history — acceptance of unsigned tokens, algorithm confusion, unvalidated claims — was a failure of implementation, not of the standard. This article collects the mistakes that keep recurring in APIs using JWT and OAuth 2.0, and their correct counterparts.
Classic JWT mistakes and their controls
Mistake | Consequence | Correct practice |
|---|---|---|
Accepting alg: none | Identity forgery with unsigned tokens | Algorithm allowlist; never accept none |
HS256/RS256 confusion | Public key used as an HMAC secret | Pin the expected algorithm, validate key type |
No exp/iat checks | Tokens valid forever | Enforce time claims; short TTLs |
No aud/iss validation | One service's token accepted by another | Validate audience and issuer in every service |
Sensitive data in tokens | Payload is signed, not encrypted | Keep personal/sensitive data out of tokens |
No revocation mechanism | Stolen tokens valid until expiry | Short TTL + rotated refresh + denylist when needed |
Signature validation: one correct order
On every request the order never changes: first the signature is verified with the expected algorithm and the correct key; then the exp, nbf, iss and aud claims are checked; only then is the token's content trusted. Keys should be fetched from a JWKS endpoint by kid, with caching; key rotation is done without downtime by publishing old and new keys together for a transition period.
Token lifetimes and refresh: live short, renew often
Access tokens should live on the order of minutes; long sessions travel on refresh tokens. Current best practice for refresh tokens is rotation: each use issues a new refresh token and invalidates the old one; if an old token is ever seen twice, the whole session chain is revoked — that is the detection mechanism for stolen refresh tokens. On the OAuth 2.0 side, the standard flow for browser and mobile clients is the authorization code flow with PKCE; the implicit flow is no longer recommended.
Scopes and authority: one token should not open every door
Scopes must be defined narrowly — read separated from write, admin endpoints requiring their own scope — and the server must actually check the scope at every endpoint. In microservice architectures, add one rule: audience validation per service, so a token minted for one service is not accepted by another.
Rate limiting and brute force: insurance for identity endpoints
Token-issuing endpoints (login, refresh, client credentials) must not ship without rate limiting and anomaly monitoring; credential stuffing attacks target these endpoints first. Logging failed attempts and wiring them to alerts is where this topic intersects with logging failures (OWASP A09).
Business impact: your API is your product now
In B2B integrations, API security is directly a sales topic: the customer's integration team will ask about your OAuth flows, token lifetimes and revocation strategy. A documented, standards-aligned identity architecture shortens integration time; an indefensible design parks the project in security review. Investment in the identity layer is infrastructure for integration sales.
Frequently asked questions
Should I use opaque tokens instead of JWT?
With a single authorization server on an internal network, opaque tokens + introspection are simple and strong; when distributed validation is needed (many services, low latency), signed JWTs are practical. Both are legitimate architectures — whichever you choose, apply the validation discipline.
Where should I store tokens?
In browsers, httpOnly + Secure + SameSite cookies resist XSS better than localStorage; on mobile, use Keystore/Keychain.
How long should refresh tokens live?
Days to weeks depending on the risk profile, always with rotation and reuse detection. Define an absolute maximum lifetime for idle sessions.
Are API keys the same as OAuth?
No: an API key identifies a client; it carries no user context or scoped authority. Any scenario needing user context should use OAuth/OIDC-based tokens.
API identity security checklist
Algorithm allowlist; alg: none rejection tested
exp, iss, aud validation enforced in every service
Access token TTL in minutes; refresh tokens rotated
Key rotation plan via JWKS defined
Scopes narrow; checked per endpoint
Rate limiting and anomaly alerts on identity endpoints
Verified that tokens carry no sensitive data
SSH Yazılım provides API identity architecture design, JWT/OAuth audits and integration security consulting. Let us review your identity layer together.