blog/new-mcp-authorization-spec/

[utterances-bot]

The New MCP Authorization Specification · Den Delimarsky

A super-quick overview of the new MCP authorization specification and how it improves security and flexibility for MCP servers.

https://den.dev/blog/new-mcp-authorization-spec/

[adranwit]

What's unclear to me is whether auth should be allowed on specific tool/resource level, also it would be good to unified it with stdio server, the current proposal seems to thread MCP server as one global protected resource ?

[venkatest]

Thanks Den for sharing this. Could you please update your examples to use this or share a new examples?.

[Algvaldivia]

Hi Den,
Thanks for the article and sharing all those details and improvements.
Something that it's on my mind, the MCP server will provide a list to the MCP client, of those AS servers he is able to support? But how the MCP server will know in advance about your Contoso internal domain, or Your Okta domain, or any other one, even for login.microsoftonline.com you must provide the tenant id. For an enterprise setup-scenario it is totally valid, but in a broader public scenario, this is where the pieces don't quite add up for me.
I understand the functionality of this approach but maybe I have fallen a bit behind and I'm catch up but still missing important aspects of this approach.

Your very details explanations might help shed some light on this and make it easier to understand.

🤗

[gching]

So cool to see this, I remember the initial days of the spec when I reviewed and mentioned the same things in your post and in the new spec - modelcontextprotocol/modelcontextprotocol#133 (comment)

Developers were definitely confused on how to implement auth given this and I tried clearing it up https://x.com/gching/status/1909546425437868383

Although the original spec was slightly confusing, there was good reason to quickly ship out a first version to get the ball running. In addition, it still had the flexibility to do what we are describing now in this new spec you worked on, but this new spec definitely makes it so much clearer and I am so glad you and everyone shipped this out. It was so fun to be part of the discussions in the community but actually so freaking cool that we all had the same exact thought - making it easier to do auth for MCP. This really just simplifies it and now we can start shipping auth MCP servers

[adamanz]

Much better than passing keys like most MCP servers make you do today

[dend]

Thanks Den for sharing this. Could you please update your examples to use this or share a new examples?.

@venkatest working on this! I am currently in the process of implementing the changes in the MCP C# SDK: modelcontextprotocol/csharp-sdk#377

[grippstick]

I have downloaded and built, csharp-sdk-localden-experimental. For the life of me I am trying to get this to work in VS Code, but I only get the 401 and it never shows an auth window. I know it won't auth properly, but I at least want it to show the auth window. Does this work with that client, do I need a different level of subscription? I have been running and debugging and I just can't seem to get anywhere. Any pointers to make this work as a proof of concept in a commercially available client would be much appreciated.

[sandipchitale]

In real world the bigger context is an agent. And an agent will potentially connect to multiple MCP servers. Therefore the Authorization will have to shift to the agent level specs as well. Presumably all the MCP servers will be participants of that single authentication and authorization scheme. If a user accessing an agent or a system of agents has to authenticate with/for each MCP server separately that is a very bad UX. It is almost as if some of this needs to be promoted to Google A2A protocol.

This https://github.com/google-a2a/A2A?tab=readme-ov-file#protocol-enhancements seems to anticipate that move.