Because the resource parameter only influences issuance. The real enforcement happens when the receiving API compares its expected audience with the token’s aud claim and rejects mismatches. Without that validation, the token can still be accepted outside the intended resource boundary.
Why resource indicators help, and where they stop helping
Resource indicators narrow where an authorization server should issue a token, but they do not by themselves enforce where that token can be used. The replay risk drops only when the receiving API treats the audience as an access boundary and rejects tokens whose aud claim does not match its expected resource. That is the control point that prevents token reuse outside the intended scope.
In practice, the distinction is between issuance-time intent and acceptance-time enforcement. Resource indicators tell the token issuer which resource the client wants, while audience validation tells the API whether that token was really meant for it. If the API skips that check, a token can still be replayed wherever the token format and surrounding trust model allow it.
What fails when the API trusts the token too broadly
The main failure is audience confusion: a token minted for one resource is accepted by another because the API does not verify the intended recipient. That weakens the boundary between services and can turn a scoped token into a portable bearer credential. The issue is not the presence of a resource indicator, but the absence of enforcement at the point of use.
This is why replay risk is reduced only partially by issuance controls. A client can ask for the correct resource, but the protection disappears if downstream services ignore audience claims, accept generic tokens, or rely on token structure alone. RFC 8707: Resource Indicators for OAuth 2.0 defines the issuance side of that boundary, but the receiving API still has to validate the token it receives.
The same pattern appears in APIs generally: broken authorization is often a validation failure, not an issuance failure. OWASP API Security Top 10 is useful here because it frames the problem as control enforcement at the API boundary, not just correct token creation.
How to think about the control in real deployments
Resource indicators are best treated as a hint that helps bind token issuance to a target audience. The API must still compare the token audience to its own identity or accepted resource identifier before authorizing the call. That check is what blocks replay across services that happen to share a token issuer, gateway, or trust domain.
For deployments that already rely on sender-constrained tokens or explicit resource metadata, audience validation should still be preserved as a separate control. Defense is stronger when the token is both intended for the right resource and accepted only by that resource. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is a related example of reducing replay value, but it does not replace audience checks.
In resource-bound architectures, the receiving service should fail closed on mismatch, not infer intent from the token’s origin or from upstream routing. If multiple APIs share a platform, gateway, or authorization server, each API still needs an explicit audience policy so one token cannot drift across boundaries.
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 | Audience validation is part of preventing token reuse by the wrong API. |
| API5 — Broken Function Level Authorization | The API must reject tokens used outside the intended resource boundary. | |
| Recommendation — Verify token audience at the API boundary before accepting any request. Enforce per-resource authorization so tokens cannot invoke unintended functions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Audience-bound token acceptance depends on authenticating non-organizational callers correctly. |
| AC-3 — Access Enforcement | Rejecting audience mismatches is direct access enforcement at the receiving API. | |
| SC-23 — Session Authenticity | Replay resistance depends on ensuring the presented token is authentic for this endpoint. | |
| Recommendation — Bind API authentication rules to the intended receiving service. Reject requests when token audience does not match the protected resource. Use session and token controls that prevent reuse at unintended endpoints. | ||
Practitioner Guidance
What to verify: Confirm that every API validates the expected audience against the token’s aud claim before any authorization decision is made. If the API accepts tokens without that comparison, resource indicators are only reducing issuance ambiguity, not replay risk.
Decision rule: If a token can reach more than one service, treat audience validation as mandatory per service, even when the authorization server supports resource indicators. If the services share infrastructure, do not assume the gateway or issuer has already enforced the boundary for you.
Practitioner takeaway: Resource indicators reduce replay risk only when issuance intent is matched by acceptance-time enforcement at the API, because the security boundary is the recipient’s audience check, not the client’s request.