The common mistake is pushing JWTs into public clients instead of terminating them at an API gateway. That expands token exposure and increases the chance of leaking PII through compromised apps or interceptable client-side storage. A better pattern is Phantom or Split token handling, where the gateway validates the external token and presents a safer internal credential to the API.
Why public-client JWT handling is a design problem, not just a token-format choice
JWTs are fine as a transportable credential format, but they become risky when a browser, mobile app, or other public client is asked to hold and replay them directly. The issue is not the token type itself. It is the trust boundary: once the client becomes the token holder, the token can be exposed to local storage abuse, debugging, injection, or accidental logging, and the API has less room to contain that exposure.
That is why gateway-terminated patterns matter. With Phantom or Split token handling, the public client does not become the durable bearer of the backend credential. The gateway validates the external token and exchanges or maps it into an internal credential with a tighter blast radius, which changes both how exposure happens and how much damage a stolen token can do.
For teams, the useful mental model is that the browser or app should carry the least sensitive artifact that still preserves the user session. If the client-held JWT can reach multiple downstream services, lives long enough to be copied, or contains claims that are unnecessary outside the edge, the architecture is already giving the client more authority and more data than it needs.
What breaks when the JWT lives in the client
Client-held JWTs fail in predictable ways. They are easier to steal from compromised devices, extensions, injected scripts, rooted phones, or developer tooling. They are also easier to misuse because a bearer token does not prove intent once copied. If the token contains rich claims, teams often overpack identity and business data into something that was meant to be passed around, which expands privacy exposure every time the token is logged, decoded, or forwarded.
The other failure mode is architectural leakage. Once a public client can present the token directly to many services, each service must trust the same artifact at the same level. That weakens containment. A good edge pattern lets the gateway absorb validation, audience checks, and token translation, so internal services see a credential that is narrower, shorter-lived, and easier to govern.
Phantom and Split token approaches are useful because they separate external presentation from internal use. The outside token can remain opaque to the client-facing layer, while the internal credential is constrained to the specific backend path. That separation is often the difference between a compromised client session and a compromise that spreads into multiple internal APIs.
Why gateway termination is usually the safer pattern
Gateway termination gives teams three practical advantages: it shrinks what the client can steal, reduces where claims are exposed, and centralises validation logic. It also creates a better enforcement point for audience restriction, token lifetime, logging hygiene, and session revocation. In practice, that means the API is not asking every public client to be both a UI and a security boundary.
This is especially important when the token carries personal data, tenant identifiers, or scopes that should not be visible to the client at all. A gateway can validate the external token once, then issue a safer internal credential or forward only the minimum necessary context. That pattern aligns better with zero trust thinking because trust is asserted at the edge and then narrowed again before the request reaches the backend.
For distributed systems, the benefit is also operational. When token handling is centralised, policy changes, audience changes, and revocation logic are easier to control consistently. When every app stores and replays JWTs on its own, the team ends up debugging security posture across multiple client runtimes instead of enforcing one edge pattern.
Risk and Threat Considerations
Putting JWTs in public clients increases exposure because bearer tokens are copyable by design and public runtimes are easier to inspect, tamper with, or compromise. The risk is not theoretical: once a token is accessible in a client environment, an attacker often only needs one successful extraction path to reuse it until expiry.
Failure mechanism: The client becomes the durable token holder, so compromise of browser storage, app memory, logs, or injected code can expose a reusable credential that still validates at the API.
Impact: Attackers can replay the token, access backend resources, and potentially expose personal data or broader session authority, with damage limited only by the token's scope and lifetime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Public-client JWT misuse weakens authentication boundary and replay resistance. |
| Recommendation — Terminate client credentials at the edge and enforce audience-bound token handling. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWT handling depends on credential lifecycle, storage, and revocation discipline. |
| IA-9 — Service Identification and Authentication | Gateway-to-API token exchange reduces exposure of credentials used by services and APIs. | |
| AC-6 — Least Privilege | Split or phantom tokens narrow what downstream services can do with a token. | |
| Recommendation — Minimize token lifetime and manage issuance, storage, and revocation centrally. Use intermediary credentials for backend calls instead of exposing client bearer tokens. Constrain downstream access to the minimum authority needed for each API call. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Gateway termination aligns with edge verification and reduced implicit trust in clients. |
| Recommendation — Place verification at the policy enforcement point and avoid trusting client-held credentials. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Bearer token handling intersects with authentication assurance and session risk. |
| Recommendation — Prefer phishing-resistant or narrowly scoped authentication flows where the client is untrusted. | ||
Practitioner Guidance
What to verify: Confirm whether the client actually needs a bearer token for direct API access, or whether the edge can terminate the external credential and issue a narrower internal one. If the answer is "direct access", test the blast radius of a stolen token before accepting the design.
Common mistake: Teams often treat JWTs as safe because they are signed, then overlook that signing protects integrity, not confidentiality or replay. A signed token in insecure client storage is still a credential that can be stolen and reused.
What good looks like: The public client holds the smallest practical artifact, the gateway performs validation and audience enforcement, and backend services never depend on a long-lived client-owned token that can travel beyond its intended boundary.
Practitioner takeaway: The design question is not whether JWTs are acceptable, but where the trust boundary should sit. If the client is the bearer, you inherit client compromise risk; if the gateway is the bearer, you can contain that risk and narrow what downstream systems ever see.
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to publish composed GraphQL services directly to clients?
- What do teams get wrong when they let AI remember prior security judgments?
- What do teams get wrong when they validate JWTs for APIs?
- What do teams get wrong when they trigger workflows directly from security lake events?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
