2026-09-24 · 8 min read
- oauth
- jwt
- security
OAuth resource indicators let a client tell an authorization server which protected resource it intends to access. The server can use that input to issue a token whose audience and privileges are narrower than a token accepted across an entire platform.
Resource indication improves least privilege only when the authorization server enforces client and user policy, token caches remain isolated, and each API validates that the token was issued for it.
Create a canonical resource registry
Assign stable resource identifiers to protected APIs and document exact URI comparison, aliases, environment boundaries, and ownership. Keep the identifier distinct from a discovery URL, request endpoint, tenant name, or arbitrary browser origin unless the provider profile defines that mapping.
- Use HTTPS identifiers under controlled domains.
- Do not infer resources from untrusted forwarding fields.
- Separate production and non-production audiences.
- Version identifiers only when policy requires it.
Define authorization-server policy
For each client and grant type, specify allowed resources, scope-to-resource mapping, consent presentation, multiple-resource behavior, refresh-token rules, token format, and resulting audience. Reject unknown or unauthorized values with protocol-compliant errors.
At the authorization endpoint, bind approved resources to the browser transaction. At the token endpoint, verify that resource requests remain compatible with that grant, redirect flow, client authentication, PKCE record, and server profile.
Partition client token caches
Key cached access tokens by issuer, client, subject or workload context, resource, normalized scope set, token type, and other authorization dimensions. Reusing a token based only on scopes can send a credential for API A to API B.
When refreshing, follow the provider's rules for retaining or narrowing resources. Do not silently retry with a broad default audience after a targeted request fails; surface the policy mismatch for correction.
Validate at every resource server
Verify signatures using keys bound to the trusted issuer, or use authenticated introspection for opaque tokens. Then validate issuer, audience, expiration, token status and type, required scopes or authorization details, and request-specific policy.
Gateways may centralize some checks, but downstream services need a trustworthy identity and authorization contract. Never treat decoded JWT claims, network location, or a gateway-added audience header as sufficient without authenticated provenance.
Exercise cross-resource failures
Use Flashman's URL parser for harmless identifiers, JWT decoder for synthetic structures, JSON formatter for sanitized metadata, diff for protocol traces, and hash tool for public fixture identity. Use maintained libraries for production verification.
Test omitted, repeated, malformed, unauthorized, and redirected resources; one and multiple resources; code and refresh grants; cache collisions; opaque and JWT tokens; audience strings and arrays; issuer mix-ups; gateway paths; revocation; and key rotation.