RFC 8707 — Resource Indicators

Specification: RFC 8707

Resource Indicators allow clients to specify which resource server(s) the access token will be used with, enabling audience-restricted tokens and improved security.

Status

Implemented. Checked claims: 7 of 7.

Authorization request

• resource parameter — specify target resource server(s)
• Multiple resource parameters — request access to multiple resources
• invalid_target for a value that is not a well-formed URI, is not registered for the client’s tenant, or does not list the client in its audience
• Without a resource parameter the audience defaults to the client’s public resources plus the resource://edge indicator
• An explicitly requested internal resource is named resource://{resourceId}, and cannot be combined with resource://edge

Token response

• aud claim in the access token — contains the requested resources, or the defaults above when none were requested
• Introspection answers with the audience the introspecting caller is entitled to see (see RFC 7662)

Resource credentials

Resources can be registered as internal or public:

• Internal resources are issued a generated credential. Edge authenticates to them on the caller’s behalf with Authorization: Basic using that credential, instead of forwarding the caller’s own access token.
• Public resources have no credential. Edge forwards the caller’s original access token as-is, so the resource server itself is responsible for validating the token’s audience.

Internal resource credentials support rotation (a previous credential remains valid until explicitly deleted), mirroring how OAuth client secrets are managed.

Benefits

Resource indicators provide:

• Audience-restricted tokens (tokens valid only for specific resource servers)
• Protection against token misuse between different APIs
• Fine-grained access control per resource

Where to look

Edge explains how resources and audiences are checked in front of an API.