TL;DR: Teleport explains that JWTs are compact, signed credentials used for authorization in distributed systems, but weak secrets, missing signature checks, long expiries, unsafe storage and transport over HTTP can let attackers or third parties reuse them for unauthorized access. The control problem is validation, lifetime and storage discipline across every system that accepts the token.
At a glance
What this is: This article explains how JWTs support distributed authorization and where implementation mistakes turn them into reusable access tokens.
Why it matters: It matters because IAM teams and NHI owners need to treat JWT validation, expiry, and storage as governance controls, not just implementation details.
👉 Read Teleport's analysis of JWT risks for NHI authorization and token validation
Context
JWTs are signed tokens that carry claims about a subject and are commonly used to authorize access across distributed systems. That makes them a non-human identity control surface as much as an application design choice, because the token itself becomes the evidence of authority.
The governance gap is not the token format alone but the trust assumptions around it. If signature verification, expiry handling, storage location, and transport security are weak, the JWT stops acting as a bounded credential and starts behaving like a portable access grant.
For NHI programmes, the relevant question is whether every consumer of the token validates the same claims, enforces the same lifetime, and protects the same secret material. If not, the authorization boundary is inconsistent even when the token is technically valid.
Key questions
Q: What breaks when JWTs are validated or handled incorrectly in API environments?
A: Incorrect JWT handling breaks trust at the authorization boundary. If signatures are not validated properly, algorithms are misused, or tokens are accepted beyond their intended scope, attackers can impersonate users or replay access. The result is unauthorized API calls, weak auditability, and data exposure across connected services and microservices.
Q: Why do long-lived JWTs create so much risk for NHI access?
A: Because JWTs are bearer credentials, anyone who copies one can often use it until the token expires. Longer lifetimes increase the replay window and reduce the chance that revocation, logging, or user review will catch misuse before access is abused across multiple systems.
Q: What are the signs that JWT handling is failing in production?
A: Common warning signs include tokens appearing in logs, tickets, chat threads, or source code, long-lived tokens that remain valid far beyond their business need, and inconsistent validation across services. Another signal is overbroad claims that let one token unlock too many functions. These patterns indicate weak lifecycle control and excessive trust in the token itself.
Q: Should teams prioritise JWT validation or token storage controls first?
A: Start with validation because a token that is not properly verified can be abused immediately, even if storage is sound. Then tighten storage and transport controls to reduce the chance that valid tokens are copied in the first place. The two controls are complementary, but verification is the first gate.
Technical breakdown
How JWT signing and claim validation work
A JWT has a header, payload, and signature. The header declares the algorithm, the payload carries claims such as issuer, audience, subject, and expiry, and the signature proves the token was issued by a trusted party and not altered in transit. Validation should check both cryptographic integrity and claim semantics. A valid signature does not automatically mean the token is safe to accept if the audience is wrong, the expiry is stale, or the token was issued for a different trust boundary. In NHI terms, the token is a portable assertion, not a substitute for local authorization logic.
Practical implication: validate signature, audience, issuer, and expiry on every system that accepts a JWT.
Why weak secrets and the 'none' algorithm are high risk
If a JWT is signed with a weak shared secret, attackers may guess or brute-force it and then forge tokens. A second failure mode is accepting tokens that declare the none algorithm, which can bypass signature verification entirely in poorly implemented stacks. These are not abstract cryptography issues. They are identity failures because the verifier is effectively delegating trust to attacker-controlled data. For service accounts and API access, a single validation mistake can turn a compact token into unrestricted access across multiple services.
Practical implication: reject unsigned tokens, enforce strong signing keys, and pin accepted algorithms in verifier logic.
How storage and transport choices change token exposure
JWTs are often used as bearer credentials, which means possession is enough to use them. Storing them in local storage, sending them over HTTP, or leaving them active for too long increases the chance that another party can reuse them. Because the token is self-contained, the recipient does not need the original login session to continue access. That convenience is exactly what creates the governance problem: issuance and use are decoupled. In NHI environments, transport and storage controls matter as much as the token format itself.
Practical implication: keep tokens short-lived, store them in the least exposed client location, and transport them only over TLS.
Threat narrative
Attacker objective: The objective is to impersonate the token holder and gain unauthorized access to protected services, APIs, or roles.
- Entry occurs when an attacker captures a JWT through weak storage, HTTP transport, or another exposed client-side location.
- Credential abuse follows when the attacker reuses the bearer token or forges one after exploiting weak signing controls or a missing signature check.
- Impact is unauthorized access to resources, roles, or APIs until the token expires or the verifier rejects it.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
JWT validation is now part of non-human identity governance, not just application plumbing. A JWT is a portable credential that can authorize machines, services, and delegated workflows across systems. That means signature checks, claim validation, and expiry enforcement belong in the same governance conversation as secret handling and privileged access. The practitioner conclusion is simple: if a token can outlive its issuer's original context, it needs lifecycle controls, not just code-level checks.
Bearer token convenience creates an identity blast radius problem. JWTs are designed to move authority between systems without repeated server-side session lookups, but that design also amplifies the impact of any leak or weak validation point. Once a token is copied, the holder can often replay it until expiry. The practitioner conclusion is that token scope, lifetime, and transport protections must be treated as blast-radius controls.
Weak secrets and permissive algorithm handling are governance failures, not edge cases. A verifier that accepts malformed algorithms or weak signing material has effectively outsourced authorization to attacker influence. That failure mode is captured well by OWASP-NHI NHI-04 and NHI-07, because the issue is not simply token misuse but the breakdown of trust in the credential itself. The practitioner conclusion is to treat every verifier as an enforcement point with explicit algorithm and secret-strength policy.
JWT risk exposes a broader trust assumption: that authorization state is stable enough to be checked later. That assumption holds only when the token is short-lived, the claims are tightly scoped, and every consumer enforces the same rules. The article shows why distributed authorization becomes fragile when different services interpret the same token differently. The practitioner conclusion is to standardise validation logic across the full token-consuming estate.
For IAM and NHI teams, JWT governance sits at the intersection of identity, transport, and runtime trust. A token that is valid cryptographically can still be unsafe operationally if it is stored badly or accepted by the wrong audience. This is why JWT policy cannot live only in the application team. The practitioner conclusion is that NHI governance must extend to token issuance, validation, and storage patterns together.
What this signals
JWT governance is a policy problem disguised as a formatting standard. The token structure is simple, but the operational decision is whether every consumer applies the same trust rules before accepting it. That makes JWTs a natural extension of NHI control design, especially where service-to-service authorization is distributed.
When JWTs are used as bearer credentials, the security boundary shifts from login time to every verification point. Teams should watch for duplicated validation logic, inconsistent expiry handling, and token storage paths that widen the replay window rather than narrow it.
For practitioners
- Enforce token validation at every consumer Require signature verification, issuer and audience checks, and expiry enforcement in every service that accepts a JWT, including internal APIs and downstream microservices.
- Reject weak signing and unsafe algorithms Pin acceptable algorithms, refuse none, and require strong signing secrets or keys so token verification cannot be bypassed by attacker-controlled header values.
- Shorten token lifetime and replay window Set the minimum practical expiry for the access pattern, then review whether the token must remain valid across multiple services or whether narrower scoping is possible.
- Move storage away from exposed client locations Avoid local storage for bearer tokens where possible, prefer safer client handling patterns, and ensure transport always uses TLS rather than HTTP.
- Review all token consumers for claim drift Inventory every service that accepts the same JWT and compare how each one interprets claims, because inconsistent audience or role handling creates policy bypass risk.
Key takeaways
- JWTs become risky when systems trust the token format without enforcing the same validation rules at every consumption point.
- The main exposure is not just tampering but bearer reuse, especially when tokens are long-lived or stored in exposed locations.
- The strongest control is consistent verification of signature, claims, lifetime, and transport across the full token estate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | JWT verification failures let untrusted tokens be accepted as valid identity assertions. |
| NHI-07 — Long-Lived Secrets | Long expiry windows keep bearer tokens usable long after issuance or compromise. | |
| NHI-02 — Secret Leakage | Weak storage and HTTP transport expose bearer tokens to theft and replay. | |
| Recommendation — Enforce strict JWT verification so only authenticated tokens are accepted by downstream services. Shorten JWT lifetimes and revoke any access path that relies on excessively durable tokens. Protect JWTs from leakage by hardening storage paths and requiring TLS for all transport. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWT signing secrets and token lifecycle are authenticator management concerns. |
| Recommendation — Apply authenticator management controls to token issuance, verification, rotation, and expiry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | JWT claims drive access decisions across distributed services and must be consistently enforced. |
| Recommendation — Align JWT claim handling with access authorization policy across every consuming service. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Stolen or forged JWTs function as credentials that can be reused for unauthorized access. |
| Recommendation — Map JWT theft and replay patterns to credential access detections and response playbooks. | ||
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 possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Signature Verification: Signature verification is the control that checks whether a software artifact was signed by a trusted key and has not been altered. It is a core supply chain safeguard for packages and registry artifacts. Effective verification should cover every resolved dependency, not only the top-level item being installed.
- Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
What's in the full article
Teleport's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step explanation of JWT structure, including header, payload, and signature fields
- Examples of registered, public, and private claims used in real token payloads
- Implementation mistakes such as none-algorithm handling, weak secrets, and unsafe storage choices
- Transport and session design trade-offs for JWT use in distributed systems
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.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org