JWT — JSON Web Token

Expanded Definition

JWT, or JSON Web Token, is a compact token format for carrying claims between systems in a way that can be signed, and sometimes encrypted, so recipients can verify integrity without querying a central session store. In NHI operations, JWTs often represent service identities, delegated access, or short-lived authorization context for APIs and agents.

Definitions vary across vendors on whether a JWT should be treated as an authentication artifact, an authorization artifact, or both. The practical answer is that the token itself is only a container; trust depends on issuer validation, audience restriction, expiry, key management, and whether the claims accurately reflect the NHI or workload that presented it. The JWT standard in RFC 7519 defines the token structure, while operational security is shaped by the surrounding identity controls.

JWTs are not automatically safer than opaque tokens. They are easier to distribute and inspect, but that convenience can increase blast radius if they are over-scoped, long-lived, or accepted by too many services. The most common misapplication is treating a validly signed JWT as inherently trustworthy even when the token was replayed from an exposed logs, browser storage, or CI/CD environment.

Examples and Use Cases

Implementing JWTs rigorously often introduces a revocation and key-rotation burden, requiring organisations to weigh stateless validation benefits against the operational cost of limiting token lifetime and managing signing keys.

• API gateways validate a service JWT before allowing machine-to-machine access, using issuer, audience, and expiry checks to prevent cross-service token replay.
• Agentic workflows issue a short-lived JWT to an AI agent so it can call only the tools needed for one task, then the token expires automatically.
• Temporary delegation uses a JWT to pass claims from one workload to another during a controlled handoff, which can be safer than sharing a long-lived static secret.
• Incident responders often look for JWTs in logs, browser storage, and ticketing systems because exposed tokens are directly reusable until expiry or revocation.
• Security teams compare JWT handling to the NIST Cybersecurity Framework 2.0 to ensure authentication, logging, and access control are coordinated rather than treated as separate problems.

The Salesloft OAuth token breach shows how token exposure can turn into downstream access when attackers obtain reusable credentials. The same lesson applies to JWTs when they are accepted beyond their intended audience or retained too long.

Why It Matters in NHI Security

JWTs sit at the center of modern NHI trust chains because they often authorize workloads, automation, and agents without human interaction. When teams confuse token format with security posture, they miss the real controls: short expiration, scoped claims, signing-key hygiene, and strict audience enforcement. That gap matters because tokens are frequently copied into code, pipelines, tickets, and chat tools, where exposure becomes hard to detect and even harder to revoke.

GitGuardian’s State of Secrets Sprawl 2026 found 28.65 million new hardcoded secrets in public GitHub commits in 2025 alone, showing how often credentials leak into the places developers use every day. For JWTs, the danger is not the syntax itself but the assumption that a signed token is safe to reuse across systems. The same exposure pattern appears in the Guide to the Secret Sprawl Challenge, where operational convenience routinely outruns governance.

Practitioners should treat JWTs as high-value bearer artifacts and validate them against service identity, context, and expiry every time. Organisations typically encounter JWT risk only after a token has been harvested from logs, a browser, or a compromised runner, at which point token handling becomes operationally unavoidable to address.