Add resource_owner field to AuthorizationCode and AccessToken classes

[yukuanj]

Summary

This PR adds a resource_owner field to both AuthorizationCode and AccessToken classes, bonding the identity of the resource owner to the issued access tokens through the authorization flow.

Motivation and Context

This PR solves #1038 (request to add a subject to AccessToken)

OAuth 2.1 §7.4 (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-14) notes that resource servers may make access control decisions based on the identity of the resource owner (for user-delegated flows) or the client (for client credentials flows). In other words, tool calls and resource fetches often need to depend on who the token is on behalf of, not just its scopes.

Resource servers may make access control decisions based on the identity of a resource owner for which an access token was issued, or based on the identity of a client in the client credentials grant.

Therefore, it is likely that the behavior of calling a tool / fetching a resource needs to depend on the identity of the resource owner.

There was an initial attempt to solve this (#1165), but it has been closed for inactivity. That thread mentioned there was no JWT payload to build from; this change avoids that dependency entirely. The feature is token-format agnostic: it does not require JWTs and works equally with opaque tokens.

What Has Been Changed?

• AuthorizationCode class: add resource_owner.
• AccessToken class : add resource_owner.

Token Issuance & Introspection Path (in the simple-auth example):

• When generating an authorization code, the AS stores the corresponding resource_owner.
• When exchanging the code for an access token, the AS binds the resulting token to that resource_owner.
• When the RS introspects the access token, the AS includes the resource_owner in the introspection result.

How Has This Been Tested?

Tested with the simple-auth example to issue codes, tokens and introspect with resource_owner.

Breaking Changes

No breaking changes.

Types of changes

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

Checklist

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

Additional context

Naming alternatives

Issue #1038 asked for subject. In JWT ecosystems, subject (sub) is commonly the canonical identifier. This PR uses resource_owner to mirror OAuth terminology in user-delegated flows. If maintainers prefer subject, this can be trivially renamed.

[slyapustin]

Hey @pcarleton, Can you please review that PR. It's very important step for mcp being adopted in many companies.

[yukuanj]

@maxisbey Thanks for the catch! For your question

should resource_owner also be added to RefreshToken? When refreshing, the AS needs to propagate the identity to the new access token.

Yes. This makes sense. I have added the field to RefreshToken so that identity persists during refreshes. I also added resource to RefreshToken, which is the same point.

Re naming: the codebase uses subject in the JWT bearer code. No strong opinion — just flagging for consistency.

I will keep it as it is, to be consistent with the OAuth naming conventions. (Similarly, resource also corresponds to audience in JWT)