JWT liveness verification exposes the limits of stateless access

At a glance

What this is: TruffleHog’s JWT detector adds liveness verification for public-key signed tokens and shows that exposed JWTs can be found at scale, but revocation and coverage remain constrained by token design.

Why it matters: IAM, NHI, and secrets teams should treat JWT exposure as a governance problem as much as a detection problem, because stateless credentials are hard to revoke and easy to overlook once leaked.

By the numbers:

• Shared-secret-based JWTs were 28x more frequently than public-key ones in several hundred gigabytes of recent GitHub content.

👉 Read TruffleHog's analysis of live JWT detection and revocation limits

Context

JWTs are commonly used as short-lived authentication and authorisation tokens for cloud and web applications, but their stateless design changes the risk model. Once a token is leaked, detection, revocation, and impact assessment become harder because the token is validated cryptographically rather than checked against a central session store.

For identity teams, this is an NHI issue as much as an application-security issue. JWTs behave like machine credentials with embedded claims, which means exposure control depends on visibility, signing-key governance, claim validation, and downstream revocation design, not just on finding the secret after the fact.

Key questions

Q: How should security teams handle leaked JWTs that cannot be centrally revoked?

A: Treat them as time-bounded but live access, not as ordinary text secrets. First identify the issuer, token lifetime, and downstream applications that trust the token. Then decide whether key rotation, application-level revocation, or forced expiry is the least disruptive way to close the access path without breaking unrelated services.

Q: Why do JWTs create different risk than API keys in identity programmes?

A: JWTs embed identity and authorisation claims inside the credential, so a leaked token can carry both proof and permission. That makes exposure more consequential than a simple identifier, while also making remediation harder when the application trusts signature validation instead of a revocation database.

Q: What should teams get wrong about JWT liveness detection?

A: They should not treat local liveness checks as the same thing as business-authorised access. A token can validate cryptographically and still be unusable in the real application, or vice versa if issuer settings and runtime policy have changed. Detection is useful, but application context still decides actual impact.

Q: How do security teams reduce the blast radius of exposed JWTs?

A: Limit token lifetime, improve where tokens are stored, and remove unnecessary reliance on stateless access where revocation matters. If a token type cannot be invalidated cleanly after exposure, it should be designed with much tighter expiry and stronger surrounding monitoring.

Technical breakdown

How JWT liveness verification works for public-key tokens

A JWT has three parts: header, payload, and signature. For public-key signed tokens, a scanner can first parse the structure, then validate the local claims such as expiration and not-before time, and only then fetch the issuer’s public key through OIDC Discovery to confirm the signature. That order matters because claim checks before signature checks would be unsafe in an authentication path, but it is acceptable in secret discovery when the goal is to reduce false positives. The result is a local proxy for token liveness, not a full application-side authorisation decision.

Practical implication: Treat local liveness checks as discovery support, then confirm the application context before revoking or rotating anything.

Why stateless JWTs are hard to revoke

JWTs are self-contained credentials. The application typically trusts the signature and claims rather than querying a revocation list, so a leaked token may remain usable until it expires unless the issuer changes the signing key or the application adds revocation lookups. That makes revocation operationally expensive because a key change can invalidate many tokens at once, while a revocation database removes the stateless benefit. This is why long expirations, especially legacy-style tokens, materially increase exposure windows.

Practical implication: Inventory token lifetimes and revocation paths now, because leaked JWTs become an incident response problem when no central invalidation mechanism exists.

Why shared-secret JWTs create a different detection problem

JWTs signed with HMAC-based shared secrets are far more common than public-key JWTs, but their liveness cannot usually be verified without knowing the secret itself. That changes the scanner’s role from verification to cautious detection, because reporting a token as live without strong evidence can overwhelm teams with uncertain findings. Public-key verification is therefore only a partial answer to the broader JWT exposure problem. The harder issue is that many organisations rely on token formats that were never designed for convenient external validation after leakage.

Practical implication: Prioritise token types you can actually govern post-exposure, and document which JWT classes your controls can prove live versus only suspect.

Threat narrative

Attacker objective: The attacker wants to reuse a leaked token to obtain authenticated access without triggering password-based controls or interactive login challenges.

1. Entry occurs when a JWT is exposed in logs, code, storage, or another reachable location that a scanner can discover. The exposure does not require password theft if the token itself is usable.
2. Escalation happens when the token remains valid long enough to be replayed because stateless validation does not consult a central revocation record. Long expiration and unclear issuer context extend the usable window.
3. Impact is unauthorised access to the application or SaaS service bound to the token, with privilege determined by the claims embedded in the JWT.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Stateless access creates a revocation gap, not just a detection gap. JWTs are designed so applications can validate them without a central lookup, which makes them operationally efficient and governance-light until something leaks. Once exposure occurs, the same design that reduced latency also removes the simplest invalidation path. The implication is that leaked JWTs are not ordinary secrets with a tidy reset path; they are live access artefacts whose remediation depends on how the issuer and application were built.

Live-token verification is becoming part of NHI hygiene, but it does not solve trust semantics. A scanner that can prove a public-key JWT is live gives security teams better prioritisation, yet it still only proves that the token can be validated locally. It does not prove the surrounding application will honour the same configuration or that an updated issuer policy has not changed runtime behaviour. The implication is that discovery quality and authorisation truth are separate governance problems.

JWT exposure is a secret sprawl problem with embedded claims. Unlike a bare API key, a JWT carries identity and authorisation context inside the credential itself, which makes leakage more informative to an attacker and more ambiguous to defenders. That is why scanning without context is often insufficient: the token may reveal enough to matter even when the surrounding service is unclear. The implication is that NHI programmes need discovery, attribution, and revocation planning for token-bearing identities.

Long-lived JWTs are a form of credential persistence that many IAM programmes under-model. When organisations issue tokens with long expirations or weak revocation mechanics, they create a persistence window that looks temporary in design but behaves like standing access in practice. That gap is especially visible when tokens are embedded in logs, chat exports, or code history. The implication is that lifecycle governance must extend to token design, not stop at issuance.

Stateless authentication shifts the control point from central revocation to upstream token discipline. If the application cannot reliably invalidate a leaked JWT after issue, then the issuer, the surrounding storage paths, and the claim model become the real control surface. This is why JWT security belongs in NHI governance rather than only in app-sec checklists. The implication is that teams should treat token design as identity architecture, not just a transport choice.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• For a deeper breach lens, see 52 NHI Breaches Analysis, which shows how exposed credentials become repeatable access paths when lifecycle control is weak.

What this signals

Ephemeral-looking credentials can still behave like standing access when revocation is weak. JWTs are a reminder that short-lived does not mean low-risk if the token can be replayed until expiry and the issuer cannot invalidate it cleanly. For IAM and NHI teams, that means token design belongs in lifecycle governance, not just in application engineering.

The governance signal is bigger than JWTs themselves. As more workloads, integrations, and SaaS connections rely on bearer-style credentials, teams need to know which secrets can be proven live, which can only be suspected, and which can be revoked at all. That operational map is now a basic control input for modern identity programmes.

If you are maturing your programme, compare exposed-token handling against the control themes in the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10. The practical question is no longer whether JWTs are popular, but whether your controls can close the gap once one leaks.

For practitioners

• Map JWT classes to revocation paths Document which token types rely on expiry only, which can be invalidated by signing-key rotation, and which support a central revocation check. Use that inventory to prioritise the tokens that behave like standing access.
• Separate detection from proof of liveness Record whether your scanning pipeline can verify a JWT locally, infer likely validity, or only flag exposure. That distinction reduces false confidence when tokens are found in logs, code, or shared storage.
• Shorten token lifetimes where revocation is weak Reduce the blast radius of leaked JWTs by cutting expiration windows, especially for tokens issued to SaaS integrations and cloud workloads where central invalidation is limited.
• Tighten the storage paths that expose tokens Review log pipelines, build artefact retention, and internal file sharing for places where JWTs can persist outside intended runtime use. Apply stricter default permissions and quick secret detection to those paths.
• Treat issuer context as part of identity governance Track which issuers support OIDC Discovery, which use non-routing networks, and which publish keys through non-standard methods. That context determines whether your scanner can prove a token live or only suspect exposure.

Key takeaways

• JWTs are not just authentication tokens, they are live access artefacts whose exposure can outlast simple detection.
• TruffleHog’s detector found hundreds of live JWTs quickly, while shared-secret JWTs appeared 28 times more often than public-key ones in its sample.
• Identity teams should focus on token lifetime, issuer context, and revocation design, because those controls determine whether a leaked JWT is still usable.

Key terms

• JSON Web Token: A JSON Web Token is a compact credential that carries claims about identity and authorisation in a signed structure. In practice, it often acts as a machine-facing access token, so leakage can create direct access if the signing and validation model is not tightly governed.
• Liveness verification: Liveness verification is the process of checking whether a discovered secret is still usable rather than merely present. For JWTs, that can mean validating claims locally and confirming the signature or issuer metadata, but it still does not fully prove how the target application will behave at runtime.
• Stateless authentication: Stateless authentication lets a service validate a credential without looking up session state in a central database. That design improves scalability, but it also weakens revocation options because leaked credentials may remain valid until expiry or signing-key change.
• OIDC Discovery: OIDC Discovery is a standard way for applications and scanners to retrieve identity provider metadata, including public keys used to validate signed tokens. In JWT governance, it matters because the ability to confirm a token’s signature and issuer depends on whether discovery is supported and reachable.

What's in the full article

TruffleHog's full post covers the operational detail this post intentionally leaves for the source:

• The detector logic for parsing JWT headers, payloads, and signatures before liveness checks
• The exact OIDC Discovery workflow used to verify public-key JWTs
• The edge cases TruffleHog will not verify today, including non-routing IP issuers and shared-secret tokens
• The trade-offs behind ignoring HMAC-based JWTs while preserving actionable findings

👉 The full TruffleHog post covers detector design, verification limits, and remediation constraints for exposed JWTs.

Deepen your knowledge

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