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
| Caller | Recommended method |
|---|---|
| Your own web frontend | Session cookie with HttpOnly, Secure, SameSite |
| Your own mobile app | OAuth 2.0 authorisation code with PKCE, short-lived tokens |
| Third-party apps acting for users | OAuth 2.0 with scopes |
| Server-to-server integrations | API keys or OAuth client credentials |
| Internal services | Mutual 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,issandaud. - 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.