undefined | Better HN

0 pointscruffle_duffle10mo ago0 comments

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.

0 comments

marifjeren10mo ago

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_water10mo ago

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.

marifjeren10mo ago

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.

j / k navigate · click thread line to collapse

0 comments

marifjeren10mo ago

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

meander_water10mo ago

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

marifjeren10mo ago

j / k navigate · click thread line to collapse