| name | oauth-resource-indicators |
| description | Authorized design and assessment of OAuth 2.0 Resource Indicators (RFC 8707): the resource request parameter, absolute resource URIs, multi-resource grants, and audience-restricted access tokens for the indicated protected resource(s). Use when clients or authorization servers send or require resource= at authorize or token endpoints, when APIs accept tokens without resource-aligned aud, or when downscoping tokens to a specific API URI is in scope for owned/lab systems. |
OAuth Resource Indicators (RFC 8707)
Focused methodology for RFC 8707 Resource Indicators: clients name the target
protected resource; the AS binds tokens; the RS enforces audience. Complements
OAuth/OIDC and JWT aud work; not a full redirect/PKCE or DPoP skill.
When To Use
| Situation | Direction |
|---|
resource= on authorize and/or token requests | This skill (primary) |
| Multi-API AS: token for API A works on API B | This skill + jwt-audience-issuer-checks |
| Design: downscope access tokens to a specific API URI | This skill |
| Docs/discovery mention resource indicators / RFC 8707 | This skill |
Only JWT iss/aud options, no OAuth resource | jwt-audience-issuer-checks |
| redirect_uri, PKCE, state, code interception | oauth-oidc-misconfiguration |
| DPoP / sender-constrained tokens | oauth-token-binding-dpop |
| No authorization for live AS/RS endpoints | Do not use actively |
Keywords: RFC 8707, resource indicator, resource parameter, resource URI,
audience-restricted access token, multi-resource, token downscoping, AS/RS split.
Workflow
1. Map parties and expected resources
Record AS authorize/token URLs, client type, each RS canonical absolute URI, and
whether resource is required, optional, or ignored.
| Field | Capture |
|---|
| Client | public/confidential; which APIs it should reach |
| Resource URIs | absolute URIs (no fragment) the AS accepts |
Where resource appears | authorize, token, both, or refresh |
| Token shape | opaque vs JWT; aud / resource claims |
| RS verifier | matching audience/resource or Bearer-any |
2. Validate resource URI form (RFC 8707)
Each resource value is an absolute URI; fragments are not allowed.
Multiple resource parameters may request multiple resources when supported.
GET /authorize?...&resource=https%3A%2F%2Fapi.example%2F&...
POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=...&resource=https%3A%2F%2Fapi.example%2F
| Check | Secure behavior |
|---|
| Relative path, bare host, opaque string | Prefer reject |
URI with #fragment | Reject |
http vs https, slash, port, case | Exact-match per AS docs |
| Unknown / unregistered resource | Reject (no silent global token) |
3. Authorization and token endpoint behavior
- Authorize with
resource: grant must be scoped to indicated resource(s).
- Token with
resource: access token audience must not exceed the grant;
refresh may downscope, not expand beyond the original grant.
- Omit
resource: document default (broad, registered default, or error)—
broad multi-API defaults are high risk.
- Multi-
resource: token audiences must not unlock non-listed APIs.
4. Audience binding probes (authorized dual-API)
With two in-scope resources (RS-A, RS-B) and a client you control:
| # | Probe | Secure outcome |
|---|
| 1 | Token for A, call B | Reject at B |
| 2 | No resource / broad aud on A and B | Reject if required; else gap |
| 3 | Token for A+B, call A only | OK if multi-resource granted |
| 4 | Refresh resource=B after grant only A | Reject expansion |
| 5 | Refresh with subset of granted resources | Downscope only |
| 6 | Lookalike host/path as resource | Reject if unregistered |
High severity: token for one resource URI accepted by another unrelated RS.
5. JWT / opaque alignment and remediation
- JWT:
aud (or profile resource claim) must match indicated resource(s); deep
iss/aud/azp matrix → jwt-audience-issuer-checks.
- Opaque: introspection/gateway must resolve audience server-side.
- Scope strings alone are not a substitute for resource indicators across
separate API security domains.
Apply code-quality-standards when implementing: AS allowlist absolute resource
URIs; bind grants and tokens; refuse expansion on refresh; RS enforce this
resource’s audience; clients send correct resource per API. Tests: wrong-resource
call, omit-resource policy, multi-resource downscope, fragment/relative reject,
refresh expansion deny.
Routing
| Need | Skill |
|---|
JWT iss / aud / azp matrix | jwt-audience-issuer-checks |
| OAuth redirect, PKCE, state, code leak, OIDC mix-up | oauth-oidc-misconfiguration |
| DPoP / sender-constrained tokens | oauth-token-binding-dpop |
JWT crypto (alg/kid/jku) | api-auth-and-jwt-abuse |
| Refresh rotation / reuse detection | jwt-refresh-token-patterns |
| Secure AS/RS/client implementation | code-quality-standards |
Selection: primary when resource or RFC 8707 resource→audience binding
is the focus. JWT wrong-party without OAuth resource → jwt-audience-issuer-checks.
Classic OAuth client threats → oauth-oidc-misconfiguration. PoP → oauth-token-binding-dpop.
Output Checklist
Scope And Authorization
- Authorized / lab / owned only. Named targets, CTFs, or systems you own. Do
not exercise third-party AS/RS outside written scope.
- Prefer test clients and resources you control. Dual-API accept/reject
evidence; no production token theft or cross-tenant abuse.
- Treat tokens, codes, and client secrets as credentials: redact, store offline,
rotate after production demos. Non-destructive first under your accounts.
- Implementation and hardening pairs with
code-quality-standards.
