Anti-pattern: long-lived static API keys
Updated 2026-05-07
Long-lived static API keys are a 2010-era pattern. The 2026 default for service-to-service traffic is short-lived tokens via OAuth Client Credentials, signed JWT assertions, or cloud-IAM workload identity federation. Static keys remain acceptable in narrow scenarios but should not be the default.
For broader credential context, see the API key rotation best-practice and the OAuth 2.1 explained guide.
Do
Prefer short-lived OAuth client credentials over static API keys
Client credentials produce short-lived access tokens; the credential is renewable at the token endpoint. Static API keys carry indefinite exposure and require manual rotation.
OAuth 2.1 Client Credentials Flow is the modern alternative. Major cloud providers (AWS IAM Roles for Service Accounts, GCP Workload Identity Federation) have moved entirely off long-lived static keys for service-to-service traffic.
If static keys are required, scope them tightly and rotate frequently
When OAuth or signed assertions aren't viable, scope static keys to the minimum set of operations and rotate on a 90-day schedule (sensitive) or 365-day schedule (less sensitive).
OWASP and NIST SP 800-63 recommend bounded credential lifetimes. Cloud providers' own static-key issuance includes built-in rotation reminders; following that pattern in your own service is the floor.
Use signed JWT assertions for client authentication where supported
JWT assertion-based client authentication (RFC 7521 + RFC 7523) replaces a static client_secret with a signed JWT generated per-request. The signing key replaces the secret; the assertion is short-lived.
OAuth 2.1 endorses assertion-based client authentication. FAPI 2.0 mandates it. Modern CIAM (Auth0, Curity, Ory, Zitadel) ship strong support; consumer-grade CIAM increasingly do too.
Don't
Don't use API keys for end-user authentication
Long-lived per-user tokens defeat session-management semantics, they can't be revoked through a user-facing logout flow and accumulate as the user creates and forgets them.
Standard CIAM separation: end-user auth uses session tokens (refresh + access) with rotation and revocation; API keys are for service-to-service or developer-tool scenarios where the consumer is not a user.
Don't display the full key after creation
Display the full key once at creation time. Subsequent UI views should show only a prefix or fingerprint. Perpetual full-key display creates additional leak surfaces.
GitHub, AWS, Stripe, and most modern API platforms follow this pattern. Deviating from it makes screenshots, screen-share, and shoulder-surfing all leak vectors.
Don't share the same key across multiple consumers or environments
Shared keys cannot be revoked surgically when one consumer is compromised, every consumer loses access during emergency rotation.
Standard credential-hygiene practice. Per-consumer keys add operational overhead but enable surgical revocation; shared keys make rotation an all-or-nothing event.
Don't accept keys older than your stated rotation policy
A documented 90-day rotation policy means the system should reject keys older than 90 days. Keys that exceed the policy lifetime are evidence of process failure and active risk.
Required by SOC 2 Type II and ISO 27001 controls around credential management. Production-grade systems track key age and surface violations to the security team.