Classify callers and channels
Separate browser clients, native applications, backend workloads, command-line tools, devices, and external partners. Record whether each client can keep a secret, receive redirects, use platform identity, and rotate credentials without an application update.
Classify target operations by sensitivity, reversibility, tenant impact, and exposure. A public catalog, partner import, and key-management endpoint should not share one undifferentiated credential profile.
Choose the right mechanism
Scoped API keys can be appropriate for controlled server integrations and metering. OAuth supports delegated user access and short-lived application tokens. Mutual TLS and signed requests can add proof of key possession where bearer replay presents material risk.
Do not place static secrets in browser JavaScript, mobile binaries, source repositories, URLs, or logs. Prefer short-lived workload tokens where infrastructure can establish service identity.
Validate every credential completely
For tokens, validate signature, issuer, audience, expiration, not-before time, token type, and required scopes or claims. Do not accept a token intended for a neighboring service simply because the same issuer signed it.
For keys and certificates, map the presented identifier to the intended client, environment, tenant, and allowed operations. Plan metadata caching, key rotation, certificate renewal, and emergency revocation before production.
Operate sessions and lifecycle
Browser sessions are credentials. Use secure cookie attributes, rotate identifiers after sign-in and privilege change, define idle and absolute lifetimes, and require reauthentication for high-risk operations.
Give every credential an owner, purpose, last-used signal, rotation path, and revocation path. Support overlapping credentials briefly during planned rotation and remove unused authority promptly.
Implementation checklist
- Inventory clients and whether they can keep secrets.
- Use separate credentials per integration and environment.
- Validate issuer, audience, time, type, and signature.
- Keep tokens, keys, and session identifiers out of logs.
- Support rotation, revocation, expiration, and ownership.
- Pass authenticated identity into resource authorization.
Frequently asked questions
Are API keys insecure?
API keys are bearer credentials and can be safe enough for some controlled server integrations when scoped, stored securely, rotated, and monitored. They are a poor fit for public clients that cannot keep secrets.
Does OAuth replace authorization in the API?
No. OAuth can issue a token with delegated or application authority, but the resource server still must authorize the requested action and object.
When is mutual TLS useful?
It is useful for strong workload or partner identity when certificate issuance, rotation, revocation, and trust stores are well managed. It should complement—not replace—application authorization.
