Access Tokens: The Thing...

## Common Pitfalls to Avoid OAuth looks neat in diagrams, but most real-world incidents come from implementation mistakes, not the spec itself. The OAuth working group’s security BCP (now RFC 9700) and OWASP’s OAuth cheat sheet both call out the same recurring OAuth pitfalls: wrong flows, weak validation, insecure storage, and overly permissive tokens. … - You may accept tokens that don’t carry the user information or assurances you think they do. - You end up bolting application-level “login” logic onto access tokens that were never designed for that purpose. Use OIDC / ID tokens, or a separate authN system, for “who is this user?”, and keep OAuth 2.0 for APIs focused on “what can this client do on this API?” ### Skipping full token validation in your APIs Another frequent pitfall is only checking that “a token is present” without actually validating it. Both RFC 9700 and OWASP recommend strict, server-side validation for every API call: signature, issuer, audience, expiry, and scope. At a minimum, your resource server should: - Verify the token’s signature against a trusted key set (JWKS). - Check `iss` (issuer), and `aud` (audience) match what your API expects. - Enforce expiry and reject expired tokens, rather than relying on the client. - Confirm required scopes (and any critical claims such as tenant ID). … ### Using the wrong flows Many vulnerable deployments still rely on flows the community now considers unsafe: - Implicit grant – returns tokens in the browser URL fragment; OAuth 2.1 drops it due to token leakage risks. - Resource Owner Password Credentials (password grant) – has the app collect the user’s username/password directly, now formally deprecated and omitted from OAuth 2.1. … ### Over-permissive scopes and long-lived tokens Duende, LoginRadius, and the OAuth security BCP all highlight the same pattern: overly broad scopes and long-lived access tokens are a gift to attackers. Common smells: - Scopes like `full_access`, `root`, `admin_all` are used across multiple APIs. - Access tokens are valid for hours or days, not minutes. A stolen token with `full_access` and a long lifetime is effectively a roaming admin credential. Instead: - Model scopes around capabilities (read/write per domain) and keep them as narrow as possible. - Issue short-lived access tokens and rely on refresh tokens or re-auth for longer sessions. This is one of the most critical levers for reducing the blast radius of token compromise in OAuth 2.0 for APIs. ### Exposing client secrets and storing tokens badly Another recurring set of issues comes from treating secrets and tokens as if they were just another config value. Both OAuth BCPs and multiple security write-ups explicitly warn against: - Shipping client secrets inside SPAs or mobile apps, where they can be extracted from JS bundles or binaries. - Storing access or refresh tokens in `localStorage` insecure cookies or logs that can be accessed via XSS or other means. … ### Flying blind: no monitoring of token usage or failures Finally, a more subtle pitfall: assuming that once you’ve “configured OAuth,” you’re done. In practice, OAuth 2.0 is a high-value target; PortSwigger and others regularly document attacks that exploit weak implementations and misconfigurations rather than the protocol itself. If you don’t monitor how OAuth 2.0 for APIs behaves at runtime, you miss: - Spikes in `401`/`403` errors indicate misconfigured clients or brute-force attacks. - Unusual scope usage (e.g., rarely used admin scopes suddenly getting busy). - Access tokens arriving in query strings instead of headers. An observability layer like Treblle helps close this gap by capturing request/response metadata, status codes, and auth headers, masking sensitive values before they leave your stack. That gives you a safe way to see where flows are failing, which clients are misbehaving, and where scope or lifetime tuning might be needed, without turning your logs into a second credential store. Avoiding these pitfalls doesn’t require inventing new security patterns; it mostly means following the existing OAuth BCPs, OWASP guidance, and treating tokens and flows with the same discipline you already apply to passwords and keys. … ### Validate every token on every request Your APIs should verify the signature, issuer (`iss`), audience (`aud`), expiry, and required scopes for each call, following the OWASP OAuth cheatsheet and RFC 9700 guidance. Never accept bearer tokens in query strings (a behavior OAuth 2.1 explicitly forbids) and never rely on the client to “do the right thing” without server-side checks.