feat: support advanced token target audience validation in addition to RFC8707 #763

This is more of a discussion item for now based on a chat with @mcguinness. Related item: oauth-wg/oauth-v2-1#215

If OAuth 2.1 included the RFC 8707 Resource Indicators for OAuth 2.0 extension, clients could expect an authorization server to process the resource or return invalid_target error code. This would help projects like MCP mitigate risks of using metadata based discovery. An authorization doesn't need to support resource indicators to be complaint. It just needs to return invalid_target if a resource is specified. . This is small lift for an authorization (support an error code) has a ton a value for dynamic discovery scenarios.

Alternatively, OAuth 2.1 could specify a new token response field for audience. This would push validation to the client to ensure the that issued token was for an audience it wanted and prevent forwarding a token to a resource server with a mismatched audience. Since audience doesn't need to be 1:1 to a resource's url this is problematic but could be profiled.

Flow proposed by @jaredhanson:

• MCP/OAuth client makes a protected resource request, receives a 401 challenge with resource_metadata parameter, per section 5.1 of RFC 9728.
• MCP/OAuth client fetches protected resource metadata, and obtains resource identifier from resource parameter and authorization server issuer identifiers from authorization_servers parameter.
• MCP/OAuth client fetches authorization server metadata.
• MCP/OAuth client makes an authorization request, including a resource parameter set to the resource identifier obtained in step 2, per section 2.1 of RFC 8707.
• Authorization server processes the authorization request and, if authorized, issues an authorization code.
• MCP/OAuth client exchanges the authorization code for access token
• Authorization server includes (new) resource parameter in token response.
• MCP/OAuth client verifies that resource parameter in token response matches the resource identifier obtained from metadata in step 2.
• Assuming verification passes in step 8, MCP/OAuth client uses access token to make protected resource request.

Work here is dependent on standard extension and AS support.