Common Auth Mistakes

Trusting unvalidated tokens

The most dangerous mistake of all is treating a decoded token as though it were a trustworthy one. Reading a JWT's claims after merely decoding it, without verifying the signature, issuer, audience, and expiry, lets a forged token carrying attacker-chosen claims pass straight through your defences. Decoding is not validation, and acting on decoded-but-unverified claims is acting on data an attacker may have written.

Always validate a token fully before acting on any claim it contains, with no exceptions for tokens that "look fine". Closely related traps in the same family include accepting the alg=none algorithm, which declares a token needs no signature, and failing to check the audience, which lets a token meant for another service be replayed against yours. The complete checklist of what to verify, and why each item matters, lives in Validating a JWT.

Mishandling secrets and tokens

A whole category of breaches comes down to credentials ending up somewhere they can be read. Committing a client secret to source control, embedding one in a mobile app where it can be extracted, or logging the full Authorization header all leak live credentials into places that outlive the moment. Tokens left sitting in browser local storage, or pasted into URLs for convenience, are exposed in much the same way to anyone who can reach those locations.

The defences are straightforward once you know to apply them consistently. Keep secrets in a dedicated secrets manager rather than in code or config, hold tokens in secure storage rather than plain files or local storage, and actively scrub both from logs and analytics. None of this is exotic, yet its absence is behind a striking share of real incidents. Detailed storage guidance is collected in Securing Client Secrets.

Choosing the wrong flow

Some mistakes are baked in at the very start, in the choice of OAuth flow itself. Reaching for a deprecated flow such as implicit, which returned tokens directly in the URL, or trying to embed a client secret inside a public client that cannot possibly keep it confidential, undermines security before a single line of business logic is written. The wrong foundation cannot be patched over later.

The correct choices are well established and not hard to follow. Public clients, meaning mobile apps and single-page apps, should use the authorization code flow with PKCE and no secret. Machine-to-machine jobs with no user present should use the client credentials flow. Picking the flow that genuinely matches your client type is fully half the battle, and that single decision, made deliberately up front, prevents a surprising share of the security problems that follow from getting it wrong.

Over-broad scopes and no expiry plan

Two final, closely linked mistakes round out the list because they are so easy to drift into. Requesting more scopes than a task actually needs quietly widens the damage from any future leak, handing an attacker capabilities the application never used. And ignoring token expiry altogether produces brittle clients that break the instant a token lapses, because nobody designed for the renewal that was always going to be required.

Both are entirely avoidable with a small amount of forethought rather than any great effort. Request the minimal set of scopes the job needs, and design your renewal strategy up front instead of bolting it on in a panic after the first mysterious failure in production. The combination of least privilege and graceful, planned renewal between them prevents the large majority of the operational surprises that catch teams out.