Use opaque tokens outside your trust boundary and keep JWTs internal to the infrastructure. Publicly exposed JWTs can reveal user data, infrastructure details, and token claims that become part of your API contract. A gateway can convert opaque tokens into JWTs for downstream services, preserving internal convenience without exposing sensitive content to clients or browser storage.
Why public Internet clients should not receive internal JWTs directly
The key decision is where a token is allowed to exist. If a client sits outside your trust boundary, a JWT sent to that client becomes externally visible, durable, and inspectable, which increases the chance that claims, routing details, or internal naming conventions leak into places you do not control. Opaque tokens reduce that exposure because the client can present them without learning what the token means.
That boundary matters because tokens are not just session handles, they often encode authority and contextual data. When the public client only sees an opaque token, the authentication and authorization details stay inside your infrastructure, where they can be validated, transformed, and observed under your own controls.
How gateway token translation preserves internal convenience
A gateway pattern lets you keep JWT-based efficiency where it helps most, behind the edge. The gateway can accept an opaque token from the client, validate it, and then mint or translate a JWT for internal services that need claims for routing, authorization, or service-to-service decisions. That preserves internal interoperability without exposing the downstream token format to browsers or other public clients.
This approach also separates client-facing trust from service-facing trust. Public clients need only a stable opaque credential, while internal services can keep relying on structured claims, shorter validation paths, and audience-specific authorization logic. The result is a cleaner division between external access and internal policy enforcement.
What changes when tokens leave your trust boundary
Once a JWT is exposed to a public client, its contents are no longer a private implementation detail. Even when the token is signed, the claims remain readable, which can disclose user attributes, tenant structure, environment names, scopes, or other metadata that should not become part of the client contract. That can also create brittle dependencies, because clients may begin to rely on claim values that were never meant to be stable.
Opaque tokens avoid that problem by making the edge the only place where token semantics are interpreted. If a claim is useful to a browser, mobile app, or partner integration, it usually deserves to be expressed through an explicit API response or consented contract, not hidden inside a public access token.
Risk and Threat Considerations
Publicly exposed JWTs expand the blast radius of token disclosure because the token itself reveals information and may be replayed until it expires. If the same token also carries broad scope or long lifetime, compromise can become both an information exposure and an access exposure problem.
Failure mechanism: Clients retain bearer material that can be copied, inspected, or reused outside the intended boundary, and embedded claims can leak internal details or enable replay until expiry or revocation.
Impact: Attackers or unintended recipients can gain unauthorized access, infer internal architecture or user metadata, and use token contents to map downstream systems or API behavior.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Public token handling directly affects how clients authenticate to APIs. |
| Recommendation — Use opaque edge tokens to reduce client-visible authentication data and constrain replay risk. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Public Internet clients are external actors whose token-based auth needs controlled validation. |
| IA-5 — Authenticator Management | Token exposure, lifetime, and rotation are central to safe handling of bearer credentials. | |
| Recommendation — Validate external client tokens at the boundary before issuing internal credentials or claims. Limit token lifetime and rotate exposed authenticators that can be copied or replayed. | ||
Practitioner Guidance
What to verify: Confirm that any token issued to a public client is either opaque or deliberately minimal, and that the client cannot depend on internal claims for business logic. If the client truly needs attributes, expose them through the API design rather than by widening token visibility.
Decision rule: If a token can be read by a user agent, partner, or browser, treat its claims as externally disclosed data. Keep JWTs for internal service-to-service use, and prefer a gateway or token exchange layer when you need structured claims inside the platform.
Practitioner takeaway: The safest pattern is not “JWTs everywhere”, it is “semantics where they are needed and opacity where they are exposed.” That keeps client-facing access simple while preserving stronger control over internal authorization data.
Related resources from NHI Mgmt Group
- How should security teams govern sender-constrained OAuth tokens for public clients?
- How should security teams handle legacy app access when older applications still need to connect to modern cloud identities?
- How should security teams use Tailscale to connect a Chromebook without exposing the home network to the public internet?
- How should security teams handle internet-facing admin planes that can become initial access paths during active exploitation waves?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
