← All cybersecurity posts

REST API Authentication Best Practices

How your API authenticates callers shapes almost every other security decision. Here is how to choose a method and implement it safely.

Choose the method for the caller

CallerRecommended method
Your own web frontendSession cookie with HttpOnly, Secure, SameSite
Your own mobile appOAuth 2.0 authorisation code with PKCE, short-lived tokens
Third-party apps acting for usersOAuth 2.0 with scopes
Server-to-server integrationsAPI keys or OAuth client credentials
Internal servicesMutual TLS or workload identity tokens

Mixing methods is common, but each endpoint should know which it accepts.

API keys done right

API keys are simple and popular for developer platforms. To use them safely:

  • Generate long random keys with a recognisable prefix, such as sk_live_, so leaked keys can be detected by secret scanners.
  • Store only a hash of the key, like a password, and show the full key once at creation.
  • Scope keys to specific permissions and, where possible, specific resources.
  • Support rotation with overlapping validity, and expiry for high-privilege keys.
  • Send keys in headers, never in URLs where they end up in logs.
  • Never embed secret keys in frontend or mobile code. Use publishable keys with limited capability if the client needs one.

OAuth 2.0 essentials

  • Use the authorisation code flow with PKCE.
  • Request minimal scopes, and enforce scopes on every endpoint.
  • Keep access tokens short-lived, and rotate refresh tokens.
  • Validate issuer, audience and expiry on every token.

JWT validation essentials

  • Verify the signature with a pinned algorithm.
  • Check exp, iss and aud.
  • Do not put sensitive data in the payload.
  • Plan for revocation.

See our JWT security guide for the full list of pitfalls.

Transport security

  • HTTPS everywhere, with HSTS.
  • Reject plain HTTP rather than redirecting API clients, to avoid sending credentials in the clear first.

Rate limiting and lockout

  • Rate limit authentication and token endpoints per client and per account.
  • Monitor for credential stuffing and key enumeration.

Authentication is not authorisation

A valid token proves who the caller is, not what they may do. Every endpoint must still check object-level, property-level and function-level permissions. Most serious API breaches involve authenticated callers accessing data they were not authorised to see.

Logging

Log authentication successes and failures, key creation, rotation and revocation, but never log the credentials themselves.

Testing API authentication

SecurityInfinity tests token validation, key handling, rate limits and authorisation boundaries for every authenticated endpoint, and checks your code and frontend bundles for exposed keys. Start free.

Frequently asked questions

Are API keys secure enough?

For server-to-server use, yes, when they are long, random, scoped, stored hashed, rotated and kept out of client code.

Should APIs use cookies or bearer tokens?

Cookies work well for first-party web apps. Bearer tokens suit mobile apps, third parties and integrations. Both can be secure when implemented correctly.

What is mutual TLS?

Both client and server present certificates, proving identity in both directions. It is common for internal service-to-service communication.

Find what attackers can see, before they do.

AI pentesting agents test your web app, API and cloud, and every finding comes with evidence and a fix. First report in about 10 minutes.

Stay ahead of attackers.

New vulnerabilities, breach write-ups and practical fixes. A few emails a month.