SEP-1046 and SEP-1502: Support client credentials flow via new MCP Extension mechanism #1047
Conversation
|
Hmm, the diffs are a bit messy. The reason for that is I had to uplevel the section on "Resource Parameter Implementation" out of the authorization code flow, in order to make it commonly applicable to both authorization_code and client_credentials flow. None of the content for that section was intended to be changed. |
|
|
||
| ### Authorization Flows | ||
|
|
||
| This specification defines two OAuth 2.1 flows that implementations **SHOULD** support: |
There was a problem hiding this comment.
I'm wondering if this is a "profile" thing that we need to formalize.
As in, the "maximum interoperability for human interactive MCP clients" would have a SHOULD (minimum) for authorization code, and then a "machine to machine" profile would have a SHOULD on client credentials flow.
There's not a big benefit for the machine to machine profile to support authorization code, and similarly there's not a big benefit for a human-based flow to support machine-to-machine. There's the case of someone wanting to implement both profiles, and that's fine.
There was a problem hiding this comment.
Yeah, similar with the enterprise-managed profile, which doesn't apply to MCP servers that only have consumer users and don't have users logging in through an enterprise IdP. I like the idea of profiles to make it explicit which parts of OAuth are needed to be supported by the AS.
There was a problem hiding this comment.
I expect we may revisit the spec structure again as we finalize the plan for profiles/extensions. For now, want to ensure we unblock audiences building autonomous agents. The original version of the MCP Auth spec did mention client credentials and it was dropped in the subsequent edits. This restores it, alongside guidance about when to implement it.
|
|
||
| This specification defines two OAuth 2.1 flows that implementations **SHOULD** support: | ||
|
|
||
| 1. Authorization Code Flow - Used when an end-user needs to authenticate via a user agent |
There was a problem hiding this comment.
Is this not being updated to specify support for RFC 7523 S2.2? I don't know if there's a use case for this in MCP, but I wanted to make sure this inconsistency was intentional and not an oversight.
There was a problem hiding this comment.
Catching up... this comment may refer to a prior iteration. The current version uses RFC 7523 Section 2.2.
For audiences who prefer RFC 7523 Section 2.1 for workloads, that mode is being explored by the Auth Profiles working group as part of Workload Identity Federation.
|
Hello, bringing a comment from the linked issue: I'm loving this update, but want to know why not mTLS for authentication as well? |
ochafik
changed the title
DinoChiesa
left a comment
DinoChiesa
left a comment
There was a problem hiding this comment.
Summary
This proposed change is unwarranted and unjustified. If there is a good reason for extending MCP in this way, It's not been articulated well.
Details
Why does MCP have an opinion on the grant type used by an OAuth client?
OAuth is well defined, well-specified, and now enjoys broad understanding. People know when authorization code is appropriate and when client credentials is appropriate. People understand the JWT bearer grant type. Why is the MCP spec saying anything about any of those things? Those are all about how to get a token which is not the focus of MCP.
It seems to me MCP ought to separate itself from the concern of "how to get a token", and let that be covered, as it already is, by the OAuth specifications. MCP should say "clients should use OAuth, whatever grant type is appropriate." And maybe something like "Clients MAY want to use RFC 8707."
Why is there an example for how to use client secret auth, and an example for using JWT bearer, in the MCP spec? It's completely out of place. Why is the MCP spec stipulating a requirement that clients MUST use RFC 8707? It's out of place.
Let people choose to do that, or not. Why is MCP forcing them? It's not coherent to include token grants in the MCP spec. It's weird that MCP insists on RFC 8707 compliance.
MCP already refers to RFC 8414 and I suppose others. Why can't the
MCP spec just refer to RFC 6749 and gently gesture toward (eg, "See also...") RFCs 7523 and 8707, and otherwise stay out of the business of stipulating which grant types should or should not be supported?, and which ways a client MUST specify the eventual server it will connect to?
|
Refactored client credentials into standalone extension per feedback |
| server). | ||
|
|
||
| ### Authorization Flow Steps | ||
| ### Resource Parameter Implementation |
There was a problem hiding this comment.
why did this section move?
There was a problem hiding this comment.
The commit history is now long and messy. The intention is to leave the authorization.mdx file completely untouched. After futzing with git for too long, I may just create a new, clean branch to accompany the SEP for extensions.
| Host: auth.example.com | ||
| Content-Type: application/x-www-form-urlencoded | ||
| grant_type=client_credentials |
There was a problem hiding this comment.
can we add scope to these examples as that would be best practice to request lower privileged access tokens
|
This is great, thanks @D-McAdams! Left a few minor comments |
D-McAdams
force-pushed
the
d-mcadams/client-credentials
branch
from
2534982 to
c997a94
Compare
D-McAdams
force-pushed
the
d-mcadams/client-credentials
branch
from
c997a94 to
d2744b6
Compare
D-McAdams
force-pushed
the
d-mcadams/client-credentials
branch
from
d2744b6 to
2a3bade
Compare
D-McAdams
force-pushed
the
d-mcadams/client-credentials
branch
from
2a3bade to
984f5a2
Compare
D-McAdams
changed the title
D-McAdams
changed the title
D-McAdams
force-pushed
the
d-mcadams/client-credentials
branch
from
984f5a2 to
3be0cb2
Compare
|
Update:
|
|
Just to respond to @DinoChiesa, we hear occasional feedback that a spec-level support for client credentials would be really useful. |
Apparently. But I asked why. You are telling me that some people thing it would be useful. Why? Why is it not separate? Why is the token grant, which happens outside of the protocol and is already defined in a separate standard, part of this protocol? |
|
Closed in favor of modelcontextprotocol/ext-auth#3 |
This PR adds support for OAuth 2.1 Client Credentials Flow to enable machine-to-machine authentication in the MCP authorization specification. See SEP #1046