Auth: MCP Servers are Resource Servers only. Add Protected Resource Metadata to discover Authorization Server #338
Conversation
075bc17 to
df2ebe8
Compare
df2ebe8 to
63095fb
Compare
docs/specification/2025-03-26/basic/authorization.mdx
Outdated
Show resolved
Hide resolved<
8000
/span>
63095fb to
b8b98cb
Compare
In the initial specification of authorization in MCP, the MCP server acted as both the authorization server (AS) and reseource server (RS). This makes enterprise deployments difficult where the AS is often a separate entity such as Auth0/Entra ID or others. The specification reworks the separation between AS/RS, making the MCP server an RS server only. This adds the complication that the MCP server must inform the client about the AS. We are using the Protected Resource Metadata OAuth specification for this. This is a first step into the right direction. Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com> Co-authored-by: Aaron Parecki <aaron@parecki.com> Co-authored-by: Paul Carleton <paulc@anthropic.com>
47aab66 to
ef76ec2
Compare
There was a problem hiding this comment.
The link for the OAuth 2.0 Protected Resource Metadata in section 2.3.1 points to the draft. (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13)
Shouldn't it be https://datatracker.ietf.org/doc/html/rfc9728 instead?
|
I already fixed that in #402 |
Oops! Sorry about that! |
|
I think it would be good to add more context around the refresh token. I can see it is shown in the flow and the specification mentions that refresh token handling best practices should be used. I feel it might be better to mention in which cases a refresh token should be used, otherwise the client could unnecessarily have indefinite access. It would be better to provide a reference to refresh token handling best practices (maybe https://datatracker.ietf.org/doc/html/rfc9700#name-refresh-token-protection). Also noticed that the specification directly mentions the authorization code grant and the client credentials grant but doesn't have a mention of the refresh token grant although the refresh token is referenced. |
|
The specification does not mention how the WWW-Authenticate header should look like. A sample would be useful. Thanks |
No description provided.