Gateway checks can filter obvious bad tokens, but they do not replace service-level validation. Each resource server should verify the claims it depends on, including issuer, audience, expiry, and any application-specific attributes. That keeps authorisation decisions aligned with the service that actually enforces them.
Why Gateway Validation and Resource-Server Validation Are Not the Same Thing
A gateway is useful for early filtering, but it is not the same trust boundary as the service that actually owns the data or action. The key difference is scope: a gateway can reject obviously invalid or expired tokens before they spread further, while the resource server must still make its own decision about whether the token is valid for that specific API and operation.
That distinction matters because token validity is not just a binary pass or fail. A token can be structurally valid and still be wrong for the target service, wrong for the action, or too broadly usable. The resource server is the only component that can reliably judge those claims in context.
In practice, this is why OAuth guidance emphasises audience restriction and resource-specific checks. A token intended for one API should not become a universal pass simply because an upstream gateway accepted it. The service that enforces authorisation should verify the token against its own expectations, including issuer, audience, expiry, and any application-specific claims it depends on, as described in the Resource Indicators for OAuth 2.0 standard.
What the Gateway Can Safely Do, and What It Cannot Prove
A gateway is best treated as a coarse control point. It can validate signature format, reject malformed or obviously stale tokens, enforce basic transport policy, and reduce noise before requests reach services. That is valuable for performance and for broad hygiene, but it does not prove the token is appropriate for every backend.
The limitation is that gateways usually sit outside the service's business logic. They rarely know which claims the resource server truly depends on, which downstream tenant or dataset is in scope, or which action requires a stricter decision. For that reason, gateway validation is an efficiency and protection layer, not a replacement for service-side authorisation.
For token-bound access patterns, the relevant security model is still the target resource's model, not the gateway's convenience layer. Standards such as OAuth 2.0 Security Best Current Practice and Demonstrating Proof of Possession (DPoP) both reinforce the idea that access tokens need the right audience and protection against replay, especially when tokens may cross multiple hops.
Why Resource-Server Validation Must Be the Final Decision
The resource server is the component that owns the action, data, and authorisation rule. It should verify not only that the token is cryptographically acceptable, but that it is acceptable for this exact API, tenant, scope, and request path. That is the only place where application-specific claims, fine-grained scopes, and business rules can be interpreted correctly.
This is also where failures become visible. If the gateway validates a token once and the backend trusts that decision blindly, any mismatch between the gateway's generic policy and the service's real policy becomes an exposure. The service may accept a token with the wrong audience, overbroad scope, stale entitlement context, or a claim that should have been checked against local policy.
For resource-server design, the cleanest model is to keep authentication and authorisation decisions close to the protected resource. The OpenID Connect Core 1.0 specification is useful when an implementation also needs identity assertions, but even then the backend still has to validate the claims it consumes rather than assume an upstream check is sufficient.
Risk and Threat Considerations
When a gateway is treated as the only validation point, the most common failure is trust expansion, where one upstream decision is reused for services that have different audiences, scopes, or claim requirements. That creates a path for token replay, misrouted tokens, and overly broad access to survive past the edge.
Failure mechanism: The gateway accepts a token once, but the resource server never re-checks whether the token was issued for that service and request context, so the backend inherits a decision it never actually made.
Impact: A valid token can be used against the wrong service, wrong tenant, or wrong operation, which turns a perimeter filter into an access-control bypass if the backend trusts it too far.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Resource servers must validate service-to-service tokens at the target boundary. |
| AC-3 — Access Enforcement | Backend claims drive the actual allow or deny decision for the protected resource. | |
| IA-5 — Authenticator Management | Token validity depends on lifecycle, expiry, and revocation handling. | |
| Recommendation — Require each resource server to authenticate tokens for its own trust boundary. Enforce authorisation at the resource server, not only at the gateway. Set token expiry and revocation controls that the service can rely on. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API authentication is weakened when backend token validation is missing or inconsistent. |
| API5 — Broken Function Level Authorization | The service must decide whether the caller may invoke a specific operation. | |
| Recommendation — Validate API tokens at the resource server and reject tokens not meant for it. Check function-level permissions in the service before executing the action. | ||
Practitioner Guidance
What to verify: Confirm that every resource server validates issuer, audience, expiry, and the exact claims it uses for authorisation, even if the gateway already inspects the token. If the backend does not independently check those fields, the control is incomplete.
Decision rule: Use the gateway to reduce obvious garbage and the resource server to make the final access decision. If a claim affects authorisation, it belongs in the service-level check, not only in the edge layer.
Practitioner takeaway: The safest pattern is layered validation with local trust boundaries, because the service that owns the data must also own the final interpretation of the token.
Related resources from NHI Mgmt Group
- What is the difference between a protected resource endpoint and an authorization server in MCP authentication?
- What is the difference between token passthrough and token forwarding in an MCP gateway?
- What is the difference between an MCP gateway and an MCP server in production AI architectures?
- What is the difference between a traditional API gateway and an MCP server?
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 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org