Security teams should prefer opaque access tokens for public clients, then introspect them at the gateway before forwarding an internal JWT to upstream services. This reduces the chance of exposing sensitive claims to clients and avoids application breakage if JWT contents change. The gateway can also enforce coarse-grained scope checks before any downstream call is made.
Why public clients need a different token pattern
Public clients cannot safely hold durable secrets, so the design goal is to keep the externally exposed token as low-value as possible while still allowing the client to call the API. Opaque tokens are a good fit because they carry no readable claims, which limits what a stolen token reveals and gives the gateway room to centralise validation decisions.
That separation also reduces coupling between the client and downstream services. If internal claim structures change, the public client does not need to understand them, and the API team can adjust internal authorisation logic without forcing a client-side rewrite. That is a practical advantage in mobile, browser, desktop, and other distributable applications.
For an API design lens, the main issue is not whether the client can present a token, but whether the token format leaks too much or creates unnecessary fragility. Treat the public client as an untrusted distribution point and keep the richer identity context behind the gateway boundary.
How the gateway pattern should work
The recommended pattern is to accept the public client token at the edge, validate it by introspection or equivalent server-side lookup, then issue or forward an internal JWT only after the gateway has made the trust decision. That keeps the client-facing token opaque while still allowing upstream services to work with a structured token that is easier to consume.
The gateway should also perform coarse-grained scope checks before any downstream call is made. This is where the first meaningful access decision belongs, because it prevents unnecessary traffic from reaching internal services and stops obvious misuse before it spreads deeper into the architecture. Fine-grained authorisation can still live closer to the service, but the edge should reject requests that clearly exceed the token’s permitted reach.
This pattern is strongest when the gateway becomes the enforcement point for token audience, expiry, revocation state, and basic entitlement. Used that way, the internal JWT becomes an internal representation of an already-validated decision, not a second chance to trust the public client.
For standards guidance, the OAuth model is easiest to align when you separate client-facing access from internal propagation. The OAuth 2.0 security best current practice in RFC 9700: Best Current Practice for OAuth 2.0 Security and the sender-constrained design in RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) both reinforce the need to reduce replay and token theft impact.
What to keep out of the public client token
Public clients should not receive a token that exposes unnecessary claims, broad downstream permissions, or internal implementation details. If the token is a JWT and those claims are readable by the client, you have effectively published part of your authorisation model to an untrusted endpoint, which creates both confidentiality and change-management problems.
Keeping the token opaque also helps when the internal claim set must evolve. If downstream systems depend on claims that are not meant for client consumption, place that translation inside the gateway rather than in the distributed application. That reduces the chance of application breakage when scopes, audiences, or entitlement rules are refactored.
Where API programs need a clear control baseline, the OWASP API Security Top 10 is the best external reference for the access-control and authentication failure modes that matter most here, especially broken authentication and broken object or function authorisation.
Risk and Threat Considerations
Public clients are high-risk token holders because they are distributed, inspectable, and easier to tamper with than server-side components. If the token is self-contained and rich in claims, a theft event can expose more information than the attacker needs, and a stale token can continue to function longer than the operator expects.
Failure mechanism: The client receives a token that is either too powerful, too readable, or too reusable, and the same token is then accepted by multiple services without a central re-check of audience, scope, or revocation state.
Impact: Token theft or misuse can lead to replay, privilege overreach, brittle integrations, and exposure of internal claims that should never leave the trust boundary. A gateway-introspection model reduces that blast radius by making the client token low-value and the internal JWT short-lived and purpose-specific.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Public client token handling depends on sound API authentication decisions. |
| API5 — Broken Function Level Authorization | Gateway scope checks prevent public clients from invoking functions beyond their entitlement. | |
| API6 — Unrestricted Access to Sensitive Business Flows | Coarse-grained edge checks help stop public clients from reaching sensitive flows they should not use. | |
| Recommendation — Validate client token handling and reject any flow that trusts an unverified or overbroad token. Enforce function-level checks at the gateway before forwarding requests downstream. Block access to sensitive flows at the edge before internal services are called. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The gateway enforces token-based access decisions before requests reach internal services. |
| IA-5 — Authenticator Management | Token issuance, rotation, expiry, and revocation are central to public-client API access. | |
| IA-9 — Service Identification and Authentication | Gateway-issued internal JWTs and service-to-service validation fit service authentication patterns. | |
| Recommendation — Enforce access decisions at the gateway and deny requests that exceed the token’s scope. Manage token lifetimes and revocation so public clients cannot rely on stale credentials. Use service authentication for internal calls and keep client-facing tokens separate. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This pattern reduces overbroad token use and centralises access checks at the gateway. |
| Recommendation — Centralise access control checks and remove any client path that can bypass them. | ||
Practitioner Guidance
What to verify: Confirm that the public client can authenticate as a client only to the extent your design permits, but cannot mint or reuse a token with broader backend meaning than intended. Also verify that gateway introspection actually checks audience, expiry, and revocation, not just signature validity.
Decision rule: If a claim is needed only by upstream services, keep it out of the public token and translate it at the gateway. If the client must be able to inspect the token safely, use only non-sensitive, non-authoritative data in that token and treat it as informational rather than contractual.
Practitioner takeaway: The safest pattern is to make the public token minimally informative and make the gateway the place where trust, scope, and downstream representation are decided.
Related resources from NHI Mgmt Group
- How should security teams implement Client ID Metadata Documents?
- How should security teams implement time based access controls without creating stale access?
- How should security teams implement policy based access control in existing IAM programmes?
- How should security teams implement DNS-based certificate validation without broad DNS write access?
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
