They should validate tokens at the gateway using published JWKs, cache keys safely, and continue to check audience and scope on every request. That approach supports identity providers that do not expose introspection while keeping the control point centralised. The main governance task is to ensure the validation model stays consistent across providers.
Why JWK-only validation works best at the MCP gateway
JWK-only validation is a pragmatic pattern when the issuer cannot provide live introspection. The gateway verifies the token signature against published JWKs, checks issuer and audience, and rejects requests that fail scope or expiry rules before they reach the MCP server. That keeps the trust decision at one control point instead of scattering it across tools and backends.
The important design choice is to treat JWKs as a verification input, not as a complete trust answer. A valid signature proves the token was issued by the expected party, but it does not prove the token is appropriate for this MCP audience, this action, or this request path. That is why the gateway must still enforce request-level checks on every call.
Published key sets also create an operational dependency: teams need a safe cache strategy, a clear refresh interval, and a fallback path when keys rotate. If the cache is too sticky, new tokens fail; if it is too loose, stale keys stay trusted too long. The control only works when validation and key refresh are both predictable.
What teams must keep validating on every request
Gateway validation should not stop at cryptographic correctness. The audience claim should match the MCP resource being called, the token scope should be sufficient but not broader than necessary, and the token lifetime should still be within policy. That combination prevents a token minted for one service from being replayed against another.
This is the same reason token passthrough is dangerous in loosely governed MCP deployments. If a downstream server trusts whatever arrives at the edge without its own audience awareness, the system can become permissive in ways the issuer never intended. A central gateway reduces that risk, but only if it enforces consistent rules across all providers.
In practice, teams also need to standardise how they handle issuer differences. Some identity providers publish JWKs cleanly but never expose introspection, while others support both models. The governance task is to make the validation behaviour identical enough that a provider swap does not silently weaken access control.
Where JWK-only validation can fail in real MCP deployments
There is a difference between being able to verify a token and being able to trust its continued legitimacy. JWK-only validation cannot tell you whether a token has been revoked early, whether a credential has been stolen and replayed, or whether a downstream tool has become overexposed through a broad audience claim.
That is why the gateway must be paired with key lifecycle discipline and tight token scoping. The model works best when tokens are short-lived, keys rotate on a known schedule, and the validation layer is treated as a policy enforcement point rather than a simple signature checker.
For teams running MCP at scale, the hardest failure mode is inconsistency. One gateway policy, one service with relaxed audience checks, or one cache that lags rotation can create a different effective trust model than the rest of the fleet. That is usually where abuse starts.
Risk and Threat Considerations
JWK-only validation concentrates trust in published keys and edge enforcement, so the main risk is not the lack of introspection itself but stale trust. If key rotation, cache refresh, or audience enforcement drifts, an attacker who obtains a valid token can often replay it longer or more broadly than intended.
Failure mechanism: The gateway accepts a signature as sufficient proof, while the real weakness sits in stale JWK caching, missing audience binding, or inconsistent scope checks across providers and services.
Impact: A forged, replayed, or overbroad token can gain access to MCP tools and backend actions that were never meant to be reachable from that token context, expanding blast radius across connected services.
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 | JWK-only validation is an API auth control problem for MCP traffic. |
| Recommendation — Validate tokens centrally and reject any request whose token cannot be proven for that API audience. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Published JWKs, token freshness, and rotation are authenticator lifecycle concerns. |
| IA-9 — Service Identification and Authentication | MCP traffic uses service-to-service token validation at a gateway. | |
| Recommendation — Manage token and key lifecycles so cached validation data stays current. Authenticate service interactions with bounded tokens and explicit audience checks. | ||
Practitioner Guidance
What to verify: Confirm that the gateway validates issuer, audience, scope, expiry, and key freshness on every request, not just at login or token minting time. If any one of those checks is delegated to the MCP server, you have split the control plane.
Decision rule: If an identity provider cannot introspect tokens, treat JWK publication, cache expiry, and rotation handling as part of the security control, not just plumbing. If those pieces are not observable and testable, the design is not production-ready.
What good looks like: The validation decision is deterministic across providers, token caches refresh without manual intervention, and every protected MCP route rejects tokens whose audience or scope does not match the request.
Practitioner takeaway: JWK-only validation is safe enough when the gateway does all of the policy work, but it becomes fragile as soon as key freshness, audience binding, or scope enforcement is allowed to vary by provider or by backend.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org