JWT risks for NHI authorization and token validation

At a glance

What this is: This is an explainer on JSON Web Tokens and the main implementation risks that matter when they are used for authorization.

Why it matters: JWT mistakes become NHI governance failures when tokens are used for service access, delegated integrations, and distributed application authorization.

👉 Read Teleport's explainer on JWT structure, risks, and implementation mistakes

Context

JSON Web Tokens, or JWTs, are signed data containers used to move authorization claims between systems without keeping a server-side session. In NHI governance, that convenience matters because the token itself becomes the access artifact for workloads, integrations, and automated services, which means expiry, signature validation, and storage choices all affect blast radius.

The article focuses on how JWTs support distributed authorization, but also on the failure modes that make them risky when teams treat them like disposable session helpers. That is a familiar pattern in NHI environments: the more widely a token travels, the more places there are to steal it, replay it, or trust it without proper verification.

Key questions

Q: How should security teams validate JWTs in distributed environments?

A: Security teams should validate the signature, issuer, audience, expiry, and algorithm on every request before using any claims. That validation must happen consistently across gateways, APIs, and services, because one weak verifier can undermine the entire trust chain. Treat decoded claims as untrusted input until checks pass.

Q: When do JWTs become risky for non-human identities?

A: JWTs become risky when they are used as long-lived bearer credentials for service accounts, bots, or integrations that cannot be watched like human sessions. The danger increases if tokens are broadly scoped, stored in unsafe places, or accepted without strict validation, because a stolen token can then impersonate an automated identity.

Q: What is the difference between JWTs and session cookies for authorization?

A: Session cookies usually point to server-side session state, while JWTs carry their own claims and can be verified without a central session lookup. That makes JWTs easier to distribute across services, but also harder to revoke centrally, so operational control must shift to expiry, validation, and storage discipline.

Q: Should organisations use short-lived JWTs for machine access?

A: Yes, short-lived JWTs are safer than long-lived ones for machine access, but only if validation and audience restrictions are equally strict. Short expiry limits replay value, yet it does not fix poor storage or missing signature checks. Organisations should pair short TTLs with revocation paths and consistent verification.

Technical breakdown

JWT structure and signed claims

A JWT has three parts: header, payload, and signature. The header states the signing algorithm, the payload carries claims such as issuer, audience, subject, and expiry, and the signature proves the token has not been altered. The key point is that the payload is readable, not secret, so trust comes from verification, not from obscurity. In NHI and API workflows, claims often stand in for identity attributes and authorization context, which makes signing integrity essential but insufficient on its own. If the verifier accepts the wrong algorithm, skips validation, or trusts stale claims too long, the token becomes a portable access bypass rather than a control.

Practical implication: Validate both signature and claims on every request, and never treat decoded JWT contents as trusted until verification succeeds.

JWT authorization in distributed systems

JWTs are popular because they reduce dependence on a central session store. A service can accept a self-contained token, read the claims, and authorize access even if the request lands on a different node or service than the one that issued it. That pattern works well for microservices and third-party integrations, but it also spreads trust across more enforcement points. For NHI governance, this means every API gateway, workload, and integration that consumes JWTs becomes part of the identity control plane. If one component is lax about expiry, audience, or issuer checks, the entire distributed trust model weakens.

Practical implication: Standardise token validation rules across all services so one weak verifier does not undermine the whole authorization path.

Token misuse patterns that create NHI risk

The article highlights several common mistakes: weak secrets, long expiry windows, storing tokens in unsafe places, failing to validate signatures, and sending tokens over HTTP. Each one increases the chance that a stolen token can be replayed as a valid non-human credential. For NHI contexts, the danger is amplified because tokens often belong to automation, service-to-service traffic, or delegated access where nobody is watching a human session in real time. A stolen JWT can therefore look normal while quietly granting access until expiry, unless revocation, rotation, and logging are built into the operating model.

Practical implication: Treat JWTs as credentials with lifecycle controls, not just as transport objects, and design for revocation and rapid expiry.

Threat narrative

Attacker objective: Use a stolen or tampered token to impersonate a trusted identity and access protected resources as that identity.

1. Entry occurs when an attacker obtains a JWT through insecure transport, weak storage, or leaked application state.
2. Escalation happens if the target does not verify signatures, accepts the none algorithm, or trusts oversized claim sets without proper checks.
3. Impact is unauthorized access to protected application resources, often without triggering obvious interactive login alarms.

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

JWT risk becomes an NHI governance issue the moment tokens outlive the session that created them. JWTs are often described as stateless convenience, but statelessness shifts responsibility onto validation discipline, token lifetime, and storage hygiene. In NHI environments, that means the access artifact can survive long after the original context has changed, which is why lifecycle control matters as much as cryptography. Practitioners should manage JWTs as credentials with exposure windows, not as harmless transport wrappers.

Claim trust, not token format, is the real failure mode. A signed JWT can still be unsafe if teams trust claims without checking issuer, audience, expiry, and algorithm. That is especially relevant for service accounts, bots, and delegated integrations where claims often drive authorisation decisions at machine speed. The discipline here is to separate token parsing from token trust. Practitioners should enforce strict verification rules before any authorization decision is made.

JWT storage and transport choices define the attack surface more than most teams admit. Tokens placed in weak client storage or moved over insecure channels are easier to replay than many teams assume. The problem is not limited to browser use cases, because the same pattern appears in CI/CD jobs, scripts, and integration middleware. For NHI programs, the practical lesson is to limit token exposure paths and assume any leaked token can become a reusable credential until expiry.

Ephemeral token trust debt is the hidden control gap in modern authorization stacks. Even short-lived tokens accumulate risk when systems cannot revoke them quickly or monitor where they are accepted. That creates trust debt, meaning the organisation keeps extending confidence into places it can no longer observe well. Practitioners should pair short expiries with validation consistency, token revocation paths, and logging that can reconstruct token use across services.

From our research:

• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, which shows how weak lifecycle controls extend credential risk far beyond the original issue, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For the broader secrets problem, see Guide to the Secret Sprawl Challenge for remediation patterns that reduce exposure across code, tickets, and collaboration tools.

What this signals

JWT adoption is accelerating the same governance problem that secrets sprawl created for static credentials. When tokens are copied into logs, build systems, collaboration tools, and client storage, the control surface expands faster than review processes can keep up. With 28% of secrets incidents now originating outside code repositories, according to The State of Secrets Sprawl 2026, teams should assume JWT misuse will show up in operational tooling, not just in application code.

Identity blast radius is the concept practitioners should watch. A single stolen JWT can authorize one workflow, but the broader risk is the number of systems that trust the same token format without uniform checks. That makes validation drift a programme issue, not just an implementation bug, and it is one reason NHI governance needs consistent policy across APIs, CI/CD, and integration layers.

What this means for practitioners is straightforward: shift from ad hoc token handling to a policy model that covers issuance, storage, verification, expiry, revocation, and audit. If those controls are not owned centrally, JWTs will continue to behave like portable trust packets rather than managed credentials.

For practitioners

• Enforce strict signature validation everywhere Require every service, gateway, and application to verify JWT signatures before reading claims or authorizing access. Reject tokens that use unexpected algorithms, especially the none value, and standardize validation libraries so teams do not implement inconsistent checks across platforms.
• Shorten token lifetime and scope Set the shortest expiry that operational workflows can tolerate, and keep claims narrow so each token authorizes only one audience and one purpose. This reduces the value of a stolen token and limits how far a compromised NHI credential can travel.
• Protect token storage and transport paths Avoid placing tokens in weak client storage, browser local storage, logs, or plain HTTP traffic. For automation and integration flows, prefer encrypted storage, secure transport, and tightly controlled secret handling in build and runtime environments.
• Add revocation and monitoring to JWT operations Do not rely on expiry alone. Maintain revocation options for high-risk tokens, log where tokens are accepted, and alert on unusual audience, issuer, or geographic patterns that suggest replay or misuse across NHI workloads.

Key takeaways

• JWTs are secure only when signature validation, claim checks, and algorithm enforcement are consistently applied.
• In NHI contexts, the main risk is not the token format itself but how widely a bearer token can be copied, stored, and replayed.
• Short expiries help, but they must be paired with revocation, logging, and disciplined storage to reduce the practical blast radius.

Key terms

• Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
• Bearer Token: A bearer token is a credential that grants access to whoever presents it, with no additional proof of possession beyond the token itself. That makes it convenient for distributed systems, but also high risk if copied, stored carelessly, or replayed by an attacker in NHI and API workflows.
• Claim Validation: Claim validation is the process of checking whether token fields such as issuer, audience, subject, and expiry match the expected security context. It is the control that prevents a validly signed token from being accepted in the wrong place, for the wrong system, or after its intended lifetime.
• Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.

What's in the full article

Teleport's full blog post covers the implementation detail this post intentionally leaves for the source:

• The exact JWT header, payload, and signature structure with decoded examples that help engineers validate token contents.
• The specific none-algorithm abuse pattern and the mitigation logic developers need to block it in code.
• Guidance on where JWTs should and should not be stored across browser, mobile, and desktop environments.
• The transport and expiry mistakes that create replay risk in real deployments.

👉 Teleport's full post covers JWT validation, storage, and transport pitfalls in more implementation detail.

Deepen your knowledge

JWT validation, expiry discipline, and credential storage are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a machine-access governance programme from the same starting point, it is worth exploring.