Authorization requirements referencing OAuth drafts and more

[obfuscoder]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

There seems to be a lot of changes in the MCP specification. I'm specifically concerned with the Authorization chapter. There are IETF drafts referenced and more or less given as REQUIRED. The link to the Oauth2.1 draft is already one version behind the most recent one. Also with the latest update on the website, the very new draft of client id metadata was added to the mix. This particular draft is in version 00 and it is not clear if this one is required or just an option. I wonder how implementers of MCP clients and servers should work with those moving targets.

Furthermore I think the Authorization requirements are reaching too far in defining how MCP servers define their security policies. For instance, RFC8707 and resource indicators is defined as required. Although I see the sentiment of restricting Access Tokens to be used with specific Resource Servers only, there are multiple options available to Authorization Servers and Trust Domains to incorporate this. RFC8707 is one option, but a strict separation of scope names is another. The MCP spec now force MCP servers and their Authorization Servers to support RFC8707 even though they might employ an entirely different security model.

[abhigyan17]

Excellent points about the OAuth authorization framework concerns. The complexity around RFC8707 and resource indicators is definitely a challenge for MCP implementations. From a security architecture perspective, I'd like to share some insights.

The key issue is that OAuth2.1 is designed for delegated authorization scenarios, but MCP also needs to handle service-to-service authentication where the same entity controls both sides. I'd recommend supporting multiple authorization models:

1. Resource Owner Password Flow for trusted internal scenarios
2. Client Credentials for service accounts
3. Mutual TLS as a complement to OAuth for encryption and authentication
4. Token introspection endpoints for runtime validation

Regarding RFC8707, the scope separation makes sense for security boundaries. Having a strict scope hierarchy prevents privilege escalation and keeps authorization decisions auditable. Consider also implementing token expiration windows and refresh token rotation for maximum security.

Please follow : abhigyan17 (its-htz (Hacksmith Tech Zone))