What is the difference between using one JWT and multiple JWTs in an authorisation request?

A single JWT works when one token contains everything the policy needs. Multiple JWTs are better when a request crosses identity boundaries, such as a service token and a user token. Keeping them separate preserves each token’s verification and lets policies compare claims across identities instead of flattening claims into attributes and losing trust context.

Why This Matters for Security Teams

The difference between one JWT and multiple JWTs is not a formatting preference. It changes what can be trusted, what can be proven, and what policy can safely decide at request time. A single JWT is efficient when one security principal is making one request path. Multiple JWTs become important when an authorisation decision spans identities, such as a user, a service, and an agent acting together.

Security teams often flatten these distinctions too early, which removes trust boundaries that should remain visible to policy. That creates brittle rules, weak auditability, and unclear accountability when a request is later challenged. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports strong access control and provenance, but it does not say to collapse all identities into one blob.

This matters in NHI-heavy environments because service accounts, APIs, and automation frequently act on behalf of people. NHIMG notes in the Ultimate Guide to NHIs — What are Non-Human Identities that NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes identity separation a practical control issue, not a theoretical one. In practice, many security teams discover the cost of flattening identity only after an incident forces them to reconstruct who actually authorised what.

How It Works in Practice

With one JWT, the token usually carries the claims needed for a single subject, a single audience, and a single trust context. That can work well for a straightforward service call where the caller and the policy decision are aligned. The problem starts when the request is composite. If a user triggers an agent, and the agent then invokes a backend service, one token often forces teams to merge claims that should stay distinct.

Multiple JWTs preserve those distinctions. One token can represent the user’s identity, another can represent the service or workload identity, and a policy engine can compare them at runtime. This is closer to the direction implied by NIST SP 800-53 Rev 5 Security and Privacy Controls, where access decisions should remain attributable and enforceable. For NHI operators, the key point is that each JWT can be independently verified, independently scoped, and independently expired.

• Use a single JWT when one principal, one audience, and one policy context are enough.
• Use multiple JWTs when a request crosses identity boundaries or trust domains.
• Keep token lifetimes short so each identity can be revoked or expired without impacting the others.
• Compare claims across tokens rather than merging them into one untraceable attribute set.

This model also improves audit and incident response because logs can show which identity supplied which privilege. NHIMG has documented how exposed or poorly managed NHI credentials create durable risk in Microsoft Azure Key Breach, which is a reminder that long-lived or over-consolidated tokens are hard to contain once misused. These controls tend to break down when legacy gateways only accept one bearer token and cannot preserve separate identity contexts.

Common Variations and Edge Cases

Tighter token separation often increases implementation overhead, requiring organisations to balance trust clarity against protocol complexity. That tradeoff is usually worth it, but current guidance suggests the design should fit the request model rather than forcing every workflow into one token shape.

There is no universal standard for this yet. Some systems use nested JWTs, token exchange, or policy layers that accept multiple bearer tokens and evaluate them together. Others keep one primary JWT and add a secondary proof for delegation or device posture. The right choice depends on whether the policy must distinguish actor, delegate, and workload, or whether one verified identity is truly sufficient.

Edge cases appear in brokered workflows, cross-tenant integrations, and agentic systems where a service acts on behalf of a user while also calling downstream tools. In those environments, multiple JWTs often preserve more security meaning than a single aggregated token, especially when revocation, scope, and audit need to be evaluated separately. The risk is highest when teams simplify for convenience and then lose the ability to prove which identity was authoritative for the action.

If a platform cannot verify multiple tokens cleanly, the safer alternative is usually to redesign the trust boundary rather than overload one JWT with every identity claim.

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• What is the difference between network trust and request-level identity trust?
• What is the difference between access request automation and access governance?
• What is the difference between agent authentication and agent authorisation?