What do security teams get wrong about embedding more data in JWTs?

Why Bigger JWTs Usually Make the Wrong Problem Feel Solved

A JWT is good at carrying claims, not at making stale decisions fresh. When teams pack more roles, scopes, or delegation chains into the token, they increase size and coupling without improving the trust decision itself. The real issue is whether the authorization decision still reflects current state when the user, agent, resource, or upstream policy has changed.

JWTs are often treated like portable authorization databases, but that pattern breaks down when the environment is dynamic. Once the token is issued, its claims are fixed until expiry, so any later revocation, privilege change, or delegation update is invisible unless the relying service re-checks live state or treats the token as only one input.

That is why token design and authorization design need to be separated. If a team uses a JWT to avoid querying policy, inventory, or session state, the token becomes a snapshot with a growing attack surface, not a smarter control. The more dynamic the relationship, the less safe it is to encode everything into a long-lived bearer artifact.

What Extra Claims Change, and What They Do Not

Adding more data to a JWT can reduce round trips, but it does not remove the need to validate the decision context. Scopes, entitlements, actor relationships, and delegation details are all subject to change after issuance, especially in systems where software services, automations, or agents act on behalf of someone else.

In practice, a larger token usually changes three things: it raises exposure if the token leaks, it increases parsing and trust complexity, and it extends the time a stale authorization picture can persist. None of those effects improve the quality of the decision. They only make more information available to whichever system receives the token.

This is also why “put it in the token” is a poor answer to authorization problems that depend on real-time context. If a permission depends on current delegation, current resource ownership, current risk level, or current session posture, the right control is live evaluation or short-lived proof with revalidation, not a bigger payload.

Better Boundaries for JWT Use

JWTs are most useful when the receiving service needs compact, signed assertions that do not change often during the token lifetime. They work best for stable identity claims, narrow session context, and limited-scoped access where the relying party can validate issuer, audience, expiry, and integrity without pretending the token is a live policy engine.

Token and Session Security Guide is the right starting point when the question is how to keep access tokens, refresh tokens, and JWTs from becoming replayable or over-trusted session artifacts. For workload-style authentication and trust-bound tokens, Guide to SPIFFE and SPIRE shows how to keep identity assertions narrow and verifiable rather than overloaded with business context.

For teams worried about what happens when signing material is mishandled or not retired, Microsoft Storm-0558 key breach 2023 is a concrete reminder that token integrity depends on the life cycle of the signing key as much as on the token format. On the external side, NIST AI Risk Management Framework and NIST SP 800-207 Zero Trust Architecture both reinforce the same operational idea: trust should be continuously evaluated, not permanently frozen into a token.

Risk and Threat Considerations

Overstuffed JWTs create exposure when teams start treating static claims as if they were current authority. If a token is stolen, replayed, or simply kept alive longer than the underlying relationship, the attacker inherits more context than they should and the defender has less room to revoke or narrow access quickly.

Failure mechanism: The issuing system encodes delegated rights, role data, or other state into a signed token, then downstream services trust that state too long after it has become stale or invalid.

Impact: Revocation becomes delayed, privilege changes take longer to take effect, and a leaked token can preserve access far beyond the moment the original relationship should have expired.

Practitioner Guidance

What to prioritise: Treat JWT contents as assertion data, not as the authority for every authorization decision. If the access decision can change during the token lifetime, keep the token narrow and make the service check current state before high-impact actions.

Decision rule: If a claim would be dangerous to trust after a user, service, or agent changes role, ownership, or delegation, do not rely on that claim as the final decision source. Use the token to identify the caller, then revalidate the sensitive permission separately.

What to verify: Confirm that expiry, audience, issuer, key rotation, and revocation behaviour are all aligned with the real world the token is meant to represent. A valid signature is not enough when the underlying relationship is already obsolete.

Practitioner takeaway: The safest JWT is usually the one that contains only what must be signed once, while the authorization decision remains live, bounded, and revocable.

Related resources from NHI Mgmt Group

• What do security and data teams get wrong about evaluating embedding quality?
• What do security teams get wrong about access reviews for sensitive data?
• What do security teams get wrong about business-context data classification?
• What do security teams get wrong about data visibility and NHI risk?