Announcing MCP Authentication: secure your MCP servers with PropelAuth

Model Context Protocol (MCP) is a standard for connecting AI applications (Claude, ChatGPT, Gemini) to external applications (Linear, Google Calendar, some custom code you write). It’s a popular way to give those AI applications more context.

You can ask ChatGPT a question like

Can you get me a list of sales calls I have tomorrow?

and ChatGPT can use a Google Calendar MCP server to query your calendar, process the information, and respond to you. Because MCP is an open standard, Claude/Gemini can use that same MCP server.

However, there’s one issue: you might not want to give every AI application the same level of access to your data.

The shift MCP creates

AI applications get more useful as you give them more context. That naturally pushes you toward more integrations:

• your calendar
• your ticketing system
• your CRM
• your docs
• internal tools you’ve built

At the same time, you probably don’t use just one AI application for everything. Different AI apps excel at different areas: coding, writing, analysis, searching, internal workflows, etc.

So instead of a world where integrations are occasional and static, MCP makes it normal to have:

• Many AI applications
• Many external systems
• Many connections per person or team

And this is compounded with the idea that each application & external system may have different rules like:

• “Claude Desktop can read my calendar, but not edit it.”
• “Cursor can access GitHub, but only for repos in this org.”
• “This internal AI tool can access production logs, but only for on-call engineers.”

To support this, we need a way for each application to be able to identify itself, ask for the permissions it needs, and allow the user to consent to that application receiving those permissions.

The boring-but-important step: manual registration

Traditionally, the external application requires a manual setup step where someone:

• creates an entry for “ChatGPT” (or “Claude”) in a dashboard
• copies some values over from the dashboard to their application (these are called a client ID and a client secret)
• then they are asked to consent to that application having a specific set of permissions

This works fine when you have a audience that’s good at following directions with a small number of tools & applications. But it can become frustrating as the number of times each user needs to do it increases.

What DCR changes

Dynamic Client Registration (DCR) is a way to make that “set up the requesting application” step happen automatically.

Instead of forcing the user to go through a dashboard first, the AI application can effectively say:

“Hi, I’m Claude Desktop. I want to connect to your service. Here’s what you’ll need so you can send the user back to me after they consent.”

Everything that was previously done manually (going to the dashboard, entering some information, copying some values from the dashboard to the application) is now programmatic.

This is why DCR matters for MCP: it turns a manual setup flow into a simpler automated flow.

The tradeoff: DCR makes onboarding easier, but easier isn't always more secure

In the manual registration process, a user would log in to a web application owned by the external application (Google Calendar, Linear, etc.). This meant you could always attribute the registration process to a specific user.

The dynamic client registration (DCR) spec, however, doesn’t have any opinions on how/if you should require authentication. And unfortunately, we are all a little at the mercy of the popular AI applications for how they expect DCR to be implemented. And double unfortunately, they pretty much all expect the registration endpoint to be unauthenticated.

With an open registration (DCR) endpoint, you have to worry about:

• Noise and spam (lots of junk app registrations)
• Impersonation attempts (apps claiming to be something they’re not)
• Operational risk (someone creating huge volumes of registrations)

None of these are unsolvable, but they are something you’ll need to worry about. If you support DCR, you should assume:

• you need strong rate limits
• you need a clear consent screen that helps users make the right decision
• you should treat applications created via DCR are untrusted

Summary

MCP makes it easy for AI applications to connect to external applications, but it also makes access control more important.

• AI applications get more useful with more integrations, so MCP increases the number of connections people set up.
• You need to know which AI application is requesting access, because not all AI apps should get the same permissions.
• Traditional setup flows can be too manual for this world.
• DCR enables a smoother flow: introduce the app → consent → redirect back → done
• The tradeoff is that DCR requires more protections because it can be abused.