Authentication with OAuth Indieauth to simplify registration

[allenporter]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Proposal

The current authentication proposal uses OAuth which is a standard, which is great. Using the dynamic client registration mechanism is also very helpful to reduce the burden on end users to register clients with servers.

However, there are even simpler approaches for decentralized oauth: OAuth IndieAuth is an extension to OAuth that dramatically simplifies client registration -- by removing it entirely -- and is a great fit for MCP since it is a decentralized approach.

Additional Detail

A question would be: What would be the guidance in the spec? My suggestion would be that this is a SHOULD recommendation, that is simpler to implement that dynamic client registration. In particular, I believe this is strictly easier and simpler to implement than dynamic client registration since there are no additional endpoints to create on the client and server.

As a purely selfish example, this would mean MCP clients integrate with Home Assistant MCP server authentication without any modifications or compatibility issues.

Additional info

There are some additional security precautions around url validation in relation to the client id. See https://indieauth.spec.indieweb.org/#authorization for an overview of the flow, which is essentially the same as an oauth flow.

Here are some additional references:

• See OAuth for the Open Web for a blog post that provides a broader overview
• Home Assistant Authentication API has an example of the simplicity of client setup. Here is a diagram
• Caveats/PSAs for IndieAuth

I previously mentioned this in the initial auth discussion, though there seemed to be some misunderstanding about micropub (which I think is a distraction in the spec). Just consider that an initial real world example of adoption.

[the-vampiire]

the spec is a bit confusing to follow without having the context of "micropub" as you noted.

can you summarize what problem indiauth solves, how that applies to MCP and how the solution works?

[allenporter]

There are two problems it solves:

• It removes the need to implementation of dynamic client registration endpoints by clients or servers. This can help with adoption.
• It allows existing OAuth servers that support IndieAuth to work without any modifications (for example, Home Assistant)

How it applies to MCP: Clients have an even easier way to connect to MCP servers just by using the MCP server URL as the client ID. MCP server authors that implement OAuth servers do not implement any registration/state/etc. Clients and servers don't need to handle additional storage for client ids.

The solution is straight forward simple:

• The client id is a url. That's is really the entire solution, other than some url checks.
• For an MCP server SSE endpoint url https://www.my-application.io/sse
• The client_id is a MCP server base url: e.g. https://www.my-application.io

A pretty large portion of the python-sdk implementation PR modelcontextprotocol/python-sdk#255 is dedicated to client registration. Granted the SDK still needs to support registration of a client id, the surface area for developers will be much smaller if this convention is adopted and made the default reference examples. Edit: This follows the the core MCP principle to minimize complexity for server authors.

[the-vampiire]

i dont think i follow. the client ID would be the server base URL?

the purpose of DCRM is to allow clients to dynamically register themselves with [resource+auth] MCP servers. the client ID uniquely identifies the client to the server so how would it work if they all have the same client ID (and oddly that it is the server URL)?

if the clients had unique URLs i could see a case (i think this is the micropub thing). but most of the clients i have seen are native applications that dont have a URL

[allenporter]

Yes, the client id is the redirect url or the server base url.

The current MCP authentication spec mentions a case already where when a server does not support DCR they need to provide a way to obtain a client ID which includes: Hardcode a client ID specifically for that MCP server.

With a hard coded client ID you aren't uniquely identity an MCP client. You could think of the MCP server as the client to the authentication provider, if that helps. The extension works well for simple cases like the one called out in the spec. In the case of Home Assistant, you are connecting to your own set of servers (MCP server, authentication server). You don't need to care at all about any complexity around registering clients, but you can still use open standards for authentication.

Large consumer authentication providers would not support this e.g. Google, Meta, etc wouldn't, just like they don't support dynamic client registration either.

[aaronpk]

I've been working on pulling out the "client ID as URL" part of IndieAuth into its own spec in the OAuth working group. You can find the latest version here: https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/

This is what BlueSky has implemented since they have the same problem as described here, but were not willing to deal with the complexities that Dynamic Client Registration brings along. Home Assistant also implemented client IDs as URLs (but without the metadata fetching part) from IndieAuth several years ago too.

For native apps that aren't actually running on a web server with a URL, the developer of the app can host a metadata file at the app's website. It's not really a problem for all the instances of the native app to share a client ID, because having a publicly available dynamic client registration endpoint doesn't give you any additional assurance of the app's identity either. If you want to bind tokens to a particular app instance, that's better off done using DPoP rather than a dynamically registered client secret anyway. This is also what BlueSky has opted for with their OAuth profile.