feat(auth): support resource indicators in auth flow

[xiaoyijun]

Support Resource Indicators in OAuth Flow

Motivation and Context

This PR adds support for Resource Indicators as specified in RFC 8707, which allows OAuth clients to specify the target resource for access tokens. Many modern OAuth servers (like Auth0 and Logto) implement this specification to enable more granular access control and token audience restrictions.

While RFC 8707 supports specifying multiple resources during authorization and selecting specific resources during token exchange, this implementation intentionally handles only a single resource per authorization session. This design decision aligns with our current auth flow architecture where:

1. Each auth session corresponds to one token
2. Each token is bound to exactly one resource
3. The resource-token binding is maintained throughout the authorization session

How Has This Been Tested?

• Added unit tests in auth.test.ts verifying:
  • Resource parameter inclusion in authorization URL when only one resource is provided
  • Resource parameters inclusion in authrization URL when more than one resource is provided
  • Resource parameter exclusion when not provided
• Tested integration with OAuth servers that support RFC 8707

Breaking Changes

No breaking changes. The resource support is implemented as an optional feature through:

• Optional resource() method in OAuthClientProvider interface
• Optional resource parameter in auth flow functions

Types of changes

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

The implementation follows RFC 8707 specifications while maintaining simplicity in the auth flow. The resource parameter is consistently propagated through all relevant auth operations:

• Initial authorization request
• Token exchange
• Token refresh

This ensures that tokens are always bound to their intended resources throughout the entire authorization lifecycle.

[xiaoyijun]

Hi @pcarleton 👋,

Sorry for the tag! I've noticed your amazing contributions to the OAuth implementation - you've done such constructive work in improving and solidifying MCP auth implementation. Really impressed by your expertise in this area.

This PR has been open for a while, and I would be incredibly grateful if you could spare some time to take a look when convenient. It implements Resource Indicators (RFC 8707) support in our auth flow, which I believe could be helpful for our future MCP Server as a Resource Server setup, since many modern Auth Services are implementing their resource access policies based on this RFC.

I've tried to keep the implementation simple and non-breaking, maintaining a clean 1:1 relationship between auth sessions and resource bindings. But I'm very open to suggestions and would really value your insights on this.

Again, sorry for the ping, and thank you for considering this! 🙏