[marifjeren]

That github issue is closed but:

> major concern that server hosters are on the hook to implement authorization

Doesn't it make perfect sense for server hosters to implement that? If Claude wants access to my Jira instance on my behalf, and Jira hosts a remote MCP server that aids in exposing the resources I own, isn't it obvious Jira should be responsible for authorization?

How else would they do it?

[halter73]

That github issue is closed because it's been mostly completed. As of https://github.com/modelcontextprotocol/modelcontextprotocol..., the latest draft specification does not require the resource server to act as or poxy to the IdP. It just hasn't made its way to a ratified spec yet, but SDKs are already implementing the draft.

[cruffle_duffle]

The authorization server and resource server can be separate entities. Meaning that jira instance can validate the token but not be the one issuing it or handling credentials.

[marifjeren]

Yes, this is true of OAuth, which is exactly what the latest Model context protocol is using.. What's the concern again?

I guess maybe you are saying the onus is NOT on the MCP server but on the authorization server.

Anyway while technically true this is mostly just distracting because:

1. in my experience the resource server and the authorization server are almost always maintained by the same company -- Jira/Atlassian being an example

2. the resource server still minimally has the responsibility of identifying and integrating with some authorization server, and *someone* has to be the authorization server, so I'm not sure deferring the responsibility to that unidentified party is a strong defense against the critique anyway. The strong defense is: of course the MCP server should have these responsibilities.

[meander_water]

I think the pain points will be mostly for enterprise customers who want to integrate servers into their auth systems.

For example, say you have a JIRA self hosted instance with SSO to entra id. You can't just install an MCP server off the shelf because authZ and resources are tightly coupled and implementation specific. It would be much easier if the server only handled providing resources, and authZ was offloaded to a provider of your choosing.

[marifjeren]

I'm under the impression that what you described is exactly how the new model context protocol works, since it's using oauth and is therefore unaware of any of the authentication (eg SSO) details. Your authentication process could be done via carrier pigeon and Claude would be none the wiser.