Overview
APIs need robust authentication on every request, and the mechanisms differ from browser session cookies. This lesson covers API authentication approaches and their security considerations.
Learning objectives
- Describe common API authentication mechanisms.
- Explain token-based authentication and its handling.
- Identify secure practices for API credentials.
Core concept
Because REST is stateless, APIs authenticate each request, commonly via:
- API keys — a static secret identifying a client; simple but must be kept secret and are hard to scope/rotate.
- Bearer tokens (e.g. OAuth 2.0 access tokens, JWTs) — a token presented in the
Authorizationheader; can carry scopes and expiry. - mTLS / signed requests — stronger mechanisms for service-to-service auth.
Whatever the mechanism, the token/credential must be transmitted over HTTPS, validated on every request, scoped to least privilege, and given a limited lifetime with a way to revoke/rotate.
How it works
The client includes its credential (typically a bearer token in Authorization: Bearer <token>) on each call; the server validates it — checking signature/validity, expiry, and scope — before processing. For JWTs, the server verifies the signature and claims (and must guard against pitfalls like accepting unsigned tokens). Tokens should be short-lived with refresh/rotation, and scoped so a leaked token grants minimal access. Credentials must never be embedded in client-side code or URLs (where they leak) and must travel only over HTTPS.
Practical example
A mobile client obtains a short-lived access token and sends Authorization: Bearer <token> on each API call. The server validates the token's signature, expiry, and scope on every request before serving data. The token is scoped to only the actions the client needs, expires quickly, and can be revoked. Contrast an insecure design: a long-lived API key hardcoded in the client (readable by anyone) sent over plain HTTP — easily stolen and hard to rotate.
Cybersecurity relevance
API authentication weaknesses are top API risks: missing authentication, long-lived or over-scoped tokens/keys, credentials leaked in client code or URLs, and JWT validation flaws (e.g. not verifying signatures). Because APIs are directly callable, every endpoint must authenticate; unauthenticated endpoints are a serious finding. Defenders use HTTPS, validate tokens on every request, scope and time-limit credentials, and store secrets safely; testers probe for unauthenticated endpoints and token-handling flaws.
Common mistakes
- Leaving endpoints unauthenticated or authenticating inconsistently.
- Embedding API keys/tokens in client-side code or URLs, where they leak.
- Long-lived, over-scoped tokens and JWTs whose signatures aren't properly verified.
Key takeaways
- Stateless APIs authenticate each request, commonly via API keys, bearer tokens (OAuth/JWT), or mTLS/signed requests.
- Credentials must be sent over HTTPS, validated on every request, scoped to least privilege, short-lived, and revocable/rotatable — never embedded in client code or URLs.
- Missing authentication, leaked or over-scoped credentials, and flawed JWT validation are top API risks and standard assessment targets.
Check your understanding
- Why must an API validate the caller's token on every single request?
- Name two insecure ways API credentials are commonly exposed, and how to avoid them.