Notifications
Clear all
Topic starter
24/06/2026 11:20 pm
TL;DR: A leaked API key can remain valid for years, while OAuth access tokens are typically short-lived and centrally revocable, making the blast-radius difference structural rather than cosmetic, according to Aembit. That distinction is now a governance decision about credential lifetime, rotation burden, and whether teams should move toward secretless workload identity.
NHIMG editorial — based on content published by Aembit: API keys vs OAuth: the structural risk in credential exposure
By the numbers:
- 50 microservices using API keys for five external dependencies each creates 250 credentials requiring rotation.
Questions worth separating out
Q: How should security teams decide when API keys are too risky to keep?
A: Treat API keys as too risky when a leaked credential would remain valid long enough to be exploited, when revocation depends on manual action, or when the key is shared across multiple services.
Q: When does OAuth become the better choice for service authentication?
A: OAuth becomes the better choice when access must be time-limited, scoped to specific actions, or revocable across many clients at once.
Q: What do teams get wrong about rotating API keys?
A: Teams often treat rotation as a fix when the real problem is that the credential model is persistent by design.
Practitioner guidance
- Classify every permanent API key as standing privilege Build an inventory of all keys, owners, target systems, and rotation status.
- Set migration triggers for high-blast-radius integrations Prioritise customer-facing APIs, compliance-bound services, and multi-cloud dependencies where a leaked secret would create immediate exposure.
- Measure credential rotation burden as a risk metric Track how many people and how much time it takes to rotate a key set, then treat high coordination cost as evidence that the access model is too brittle for the service estate.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- A practical decision framework for choosing between API keys, OAuth, and secretless workload identity in different service scenarios
- Rotation and migration trade-offs for teams managing many microservices and external dependencies
- Implementation details for workload identity approaches such as cloud-assigned identities and SPIFFE/SPIRE
- Specific guidance on moving legacy systems toward short-lived credentials without a big-bang cutover
👉 Read Aembit's analysis of API keys, OAuth, and secretless workload identity →
API keys vs OAuth exposure risks: what IAM teams need to know?
Explore further
25/06/2026 8:08 am
Long-lived credentials create identity blast radius, not just secret sprawl. The article shows that API keys are not merely harder to manage than OAuth tokens, they create a durable access path that survives detection delays and organisational handoffs. In NHI governance terms, the issue is not one leaked secret but the persistence of delegated access without a natural expiry. Practitioners should treat every permanent key as a standing privilege record.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: How do workload identity platforms change secret management?
A: They remove the need to store a reusable secret in the workload and replace it with runtime-based identity and short-lived access. That changes the governance model from protecting a secret forever to proving the workload’s identity at runtime. For many service estates, that is the cleanest way to reduce credential sprawl.
👉 Read our full editorial: API keys vs OAuth: the structural risk in credential exposure
