I spent a week building OAuth Plumbing that shouldn't exist

Claude's moving to proper OAuth flows. Great for security. Nightmare for everything else.

Here's the issue: OAuth Authorisation Code requires pre-registering client applications with your identity provider. You know, the normal flow where you log into some provider's admin panel, click "New Application", copy a client ID and secret, paste them into your config. Done.

That works fine when you're building a traditional web app. You register once and move on with your life.

But MCP servers are supposed to be plug-and-play. You point your AI agent at a URL and it just works. Imagine if every time you wanted to connect Claude to a new MCP server, you had to:

1. Log into your identity provider
2. Manually register Claude as a client
3. Copy credentials
4. Paste them somewhere in Claude
5. Repeat for every server, every identity provider, every user

Nobody's doing that. The friction kills the entire value proposition of MCP as a universal protocol.

The Fix Nobody Implemented

Dynamic Client Registration has existed since 2015. RFC 7591. The spec lets clients register themselves programmatically—agent hits an endpoint, says "I'm Claude, here's what I need", gets credentials back automatically. No manual steps. No copy-paste hell.

Except almost nobody supports it.

Not Entra ID. Not Cognito. Not Google Identity Platform. I found support requests from very recently with Microsoft basically saying "noted" and doing nothing.

To be fair, some providers support it. Auth0 does, but you're paying for it. Keycloak does too—it's open-source and free. But Keycloak is Java, and I'm not running a JVM just for identity management. Okta supports it if you're on their enterprise plan. Ping Identity, same deal.

Cloud providers have zero incentive to implement an obscure OAuth extension when their enterprise customers don't need it. Traditional web apps don't care—they register once and forget about it. The providers who do support DCR are either charging for it or come with infrastructure baggage I don't want.

Why I Had To Deal With This

I'm building MCP servers for personal projects. Memory systems, voice conversation tools, that sort of thing. Running ZITADEL as my identity provider because it's open-source, self-hostable, and the Management API doesn't make me want to throw my laptop out a window.

ZITADEL doesn't do DCR either.

So I built a facade. A translator that sits between MCP clients and ZITADEL, speaks RFC 7591 on one side and ZITADEL's Management API on the other.

What It Actually Does

Simple enough in concept:

1. Agent discovers the DCR endpoint from my MCP server's OAuth metadata
2. Agent POSTs to /register with what it needs
3. Facade calls ZITADEL's API to create an actual OIDC application
4. Stores the mapping (client_id → ZITADEL app ID) in Postgres
5. Hands credentials back
6. Agent proceeds with normal OAuth flow

Built with FastAPI and Postgres. Nothing exotic.

Things That Sucked

ZITADEL's API is clean but chatty. You can't create an application in one call. You create the base app, then configure OIDC settings, then add redirect URIs. Three separate calls. If step 3 fails, you need rollback logic for steps 1 and 2.

I spent more time on error recovery than registration logic.

Rate limiting was annoying too. Started with in-memory counters because simple. Then realised that breaks completely if you run multiple instances. Moved to Postgres-backed rate limits. Probably overkill. But at least it works correctly.

Why Any Of This Matters

MCP wants to be the HTTP of AI—universal protocol, works everywhere. But OAuth gatekeeps it with provider-specific nonsense. DCR should fix this. Most providers don't care because traditional customers don't need it.

AI agents change the math. They can't manually register thousands of OAuth clients across hundreds of identity providers. That doesn't scale. Either providers add DCR support or developers keep building facades.

Good news: once you've built one DCR facade, adapting it for other providers isn't terrible. The OAuth dance stays the same. Only the management API calls change. Built mine for ZITADEL but the architecture would work for any provider with a decent management API.

Still Not Done

Haven't deployed it yet. It's in staging.

Need to test the whole flow with Claude end-to-end before I call it finished. Might open-source it once I'm confident it actually works in production, but honestly the code is pretty specific to my ZITADEL setup. The architecture is probably more useful than the implementation.

If you're hitting the same problem, the approach here should translate. The RFC is straightforward once you actually read it—most of the work is wrangling your identity provider's quirks.

Built with Python 3.12, FastAPI, and PostgreSQL. For my personal MCP servers (memory systems, voice tools, that kind of thing). Not exactly exciting infrastructure, but it solves a real problem.