API keys vs JWTs: why secretless workload identity is next

At a glance

What this is: This article compares API keys and JWTs for API authentication and concludes that both remain secret-dependent models that do not scale as well as workload identity federation.

Why it matters: IAM, PAM and platform teams should treat secretless workload identity as the architectural direction when service-to-service access, CI/CD, and API credentials are spreading faster than humans can govern them.

Context

API keys and JWTs are both common ways to authenticate services, but they solve different problems and both rely on credentials that must be stored and protected. The core governance issue is not token format alone, but the lifecycle burden created when machine access depends on secrets that spread beyond the original system of record.

For identity teams, the important question is where static credentials stop being workable and where secretless workload identity becomes the safer default. Once service access needs scoped authorization, revocation, and runtime trust across CI/CD and cloud platforms, the discussion shifts from authentication convenience to governance of non-human identity.

Key questions

Q: What breaks when API keys are embedded in repositories or pipelines?

A: The identity program loses visibility, ownership, and revocation speed. Once a Bedrock key is hardcoded or logged, it can spread beyond the control of the original team and persist after the intended use ends. Discovery must therefore happen across engineering and collaboration systems, not just in the identity platform.

Q: Why do JWTs create risk when controls around signing and time claims are weak?

A: JWTs become risky when teams trust the token format more than the validation logic. If a gateway accepts unsigned tokens, ignores expiration, or mishandles not-before and issued-at checks, attackers can forge or replay access. That turns a bearer token into a durable access path, which is especially dangerous for APIs exposing sensitive functions.

Q: How do teams know when workload identity is a better fit than static secrets?

A: When access must be proven at runtime, scoped per task, and revocable without hunting through code and chat for every copy of a secret. If the workload can attest its environment and receive temporary credentials, static API keys are usually the wrong abstraction.

Q: What is the difference between workload identity federation and a static API key?

A: A static API key is a persistent secret that must be stored and rotated manually. Workload identity federation exchanges a trusted identity assertion for a short-lived token at runtime. That means access is temporary, identity-bound, and easier to govern, while the application avoids handling long-lived credentials directly.

Technical breakdown

Why API keys fail once secrets sprawl

API keys are opaque, long-lived shared secrets. They identify a caller, but they do not carry built-in context about permissions, expiry, or purpose, so enforcement moves to server-side policy and human discipline. That makes them workable for low-risk integrations, but brittle when the same key is copied into code, pipelines, local configs, and chat systems. Once a key leaks, it remains valid until manually revoked, and revocation only works if every copy can be found. In NHI terms, the problem is not the presence of a secret alone. It is the loss of control over its placement, scope, and retirement.

Practical implication: treat API keys as a narrow fit for low-risk integrations and track every place a key can be copied, stored, or reused.

What JWT claims do and do not solve

JWTs add structure by embedding claims such as issuer, audience, scope, and expiry into a signed token. That makes them more expressive than API keys for distributed systems because receiving services can validate context locally without a central session lookup. But a JWT is still a credential, and its security depends on correct validation. If signature checks, algorithm allowlists, expiration checks, or audience restrictions are weak, the token format creates false confidence. JWTs reduce ambiguity about what a service may do, but they do not remove the operational burden of key protection, signing, and revocation planning.

Practical implication: validate JWTs strictly and assume the signing material is a high-value credential that still needs lifecycle control.

How workload identity federation removes secret-zero

Workload identity federation replaces shared static credentials with runtime attestation. A service proves who it is through its execution environment, the platform verifies that identity, and a temporary credential is issued for the specific task. That breaks the secret-zero problem because there is no long-lived bootstrap key to distribute, rotate, or recover after exposure. For NHI governance, this changes the control point from secret storage to trust establishment. The critical design question becomes whether the runtime environment can be trusted to assert identity accurately enough for the downstream platform to issue access.

Practical implication: move service access design toward runtime attestation and short-lived exchange instead of distributing persistent secrets.

Threat narrative

Attacker objective: The attacker aims to reuse a valid machine credential to impersonate a service, access downstream systems, or expand access through additional secrets.

1. Entry begins when a service credential is copied into repositories, CI/CD variables, or chat threads that outlive the original deployment context.
2. Credential abuse follows when the leaked key or signing secret remains valid and can be reused from a new location without immediate detection.
3. Impact occurs when the attacker uses the credential to access APIs, impersonate the workload, or trigger broader secret rotation and service disruption.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static API credentials create identity blast radius. API keys look simple because they answer one narrow question: which application is calling. The governance failure begins when the same credential spreads into code, CI/CD, configuration, and chat, turning a single identity into many uncontrolled copies. That is not just poor hygiene; it is a structural expansion of blast radius. Practitioners should read this as a lifecycle problem, not a token-format debate.

JWTs improve context, but they do not remove secret dependency. Claims-based tokens solve the need for scoped, per-request authorisation in distributed systems, yet the signing key remains the control point. If that signing material is weakly governed, the organisation has only shifted the problem from API key reuse to token trust and key protection. The practical conclusion is that more expressive tokens do not equal secretless identity.

Secretless workload identity is the real architectural shift. The article’s important signal is not that JWTs are better than API keys, but that both remain built on stored credentials. Federation changes the trust model by making runtime environment attestation the basis for access. That re-centres governance on workload identity, not shared secrets, and it is where modern IAM and cloud operations are converging.

Secret-zero is a governance assumption, not a technical footnote. Credential-based workload access was designed for environments where a static secret could be protected long enough to bootstrap trust. That assumption fails when pipelines, services, and automation copy credentials across systems faster than teams can inventory them. The implication is that lifecycle governance must move from post-issuance control to issuance-time trust establishment.

Ephemeral trust boundary: the article points to a boundary where identity should be proven at runtime and discarded after the task completes. That concept matters because it separates human-readable configuration from machine-trusted authentication. Practitioners should treat this as the next stable design pattern for service identity.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Secret sprawl is the real scaling problem for machine access. Once a credential can be copied into repositories, CI/CD systems, and collaboration tools, the organisation loses the ability to reason about its true blast radius. Workload identity matters because it removes the need to keep rediscovering where the secret went.

Ephemeral trust changes the operating model for non-human identity. Access should be proven where the workload runs, not reconstructed later from a pile of copied secrets. That shifts governance from tracking possession to verifying runtime identity, which is the more durable control point for machine access.

For practitioners

• Audit where API keys actually live Map every repository, CI/CD variable, config file, and chat system that stores a service credential. Prioritise the keys with the widest reuse and the least reliable revocation path.
• Tighten JWT validation rules Require explicit checks for signature algorithm, issuer, audience, and expiry on every request. Block unsigned or weakly validated tokens before they become a hidden authorisation path.
• Replace persistent secrets with federated workload identity Use runtime identity attestation and short-lived exchange for services that currently depend on stored API keys or signing secrets. Keep the trust decision at issuance time instead of distributing a reusable credential.
• Separate client identification from request authorisation Where both the application and the user must be known, keep those concerns distinct so one credential does not carry every access decision. This reduces overreach when an app and a user session are governed differently.

Key takeaways

• API keys remain useful for narrow, low-risk integrations, but they become brittle when the same secret is copied across code, pipelines, and chat systems.
• JWTs improve scope and expiry controls, yet they still depend on signing keys and validation discipline, so they do not eliminate the secret problem.
• Workload identity federation changes the governance model by replacing reusable credentials with runtime proof and short-lived access.

Key terms

• API Key: A unique identifier used to authenticate a software application or service when calling an API. API keys are static, long-lived credentials and a major source of secrets sprawl. In 2024, over 50 million leaked API keys were found on the dark web.
• Jwt: A signed token format that packages claims in a compact structure made of a header, payload, and signature. It tells receivers what information is inside the token, but not how that token must be transported or stored.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.