Series: Enabling MCP at Enterprise Scale — Post 1 of 10.
MCP development is fast. Define your tools, wire up your business logic, and you’ve got something running in a few hours. The getting-started experience is genuinely good.
Then you try to connect your server to a real enterprise service — a CRM, an HR system, a cloud platform — and you run into OAuth. That’s where the timeline estimate you gave your manager stops being accurate.
This isn’t an MCP problem. It’s an OAuth problem. But because MCP authentication delegates to OAuth 2.0, it becomes your problem the moment you move past local development.
What You’re Actually Signing Up For
The MCP spec is clear: use OAuth. What it doesn’t spell out is how much engineering that involves. Here’s what a production-ready MCP authentication implementation actually requires:
Access scopes. Request the right permissions from the user, handle cases where they grant fewer than you expected, and revisit this every time the server evolves.
Callback URL handling. OAuth redirects users back to your app with an authorization code. Register the redirect URI, validate the state parameter to prevent CSRF, and exchange the code for a token — without letting any of that touch a server log.
Token refresh. Access tokens expire. Your server needs to detect that, request a new token in the background, handle race conditions when multiple requests hit an expired token at the same time, and deal gracefully with refresh token expiry.
Secure token storage. Tokens are credentials. Encrypt them at rest, lock down who can read them, rotate them, and make sure you can audit usage.
None of this is the hard part of what your MCP server is supposed to do. All of it is required before it can do it safely.
The Part the Tutorials Skip
Most MCP tutorials stop before auth. They show you how to define a tool and return a response. That’s enough to get something running locally — it’s not enough to get it past your security team.
Take a GitHub MCP server. The tool logic is simple: list repos, read a file, open a PR. You could build that in a day. But running it in an enterprise environment — per-user MCP authentication, scoped tokens, proper storage, revocation when someone loses access — that’s a different project. You’re registering an OAuth app, building the authorization flow, storing tokens per user, refreshing them in the background, and making sure your server stays in sync when permissions change in GitHub. Call it a week, before review.
That gap between “it works” and “it’s production-ready” is mostly an auth gap. Teams usually find this out later than they’d like.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
The Scale Problem
One MCP server with a solid OAuth implementation is manageable. The problem is that organizations don’t stop at one.
A BI server. An HR server. A CRM server. A customer support server. Each one needs its own MCP authentication implementation — its own token store, its own refresh logic, its own scope configuration. None of them share anything.
There’s no central place to see what tokens have been issued. No single revocation point if a credential is compromised. No unified audit trail. When your security team asks “who has access to what across our MCP infrastructure” — and they will — you don’t have a clean answer.
This is what identity sprawl looks like at the MCP layer. It’s not a future problem. It’s what happens when teams build MCP servers independently without a shared auth strategy. If you have ten MCP servers, you have ten token stores, ten refresh implementations, and ten potential points of failure.
What the Fix Looks Like
The answer isn’t better OAuth implementations in every server. It’s moving OAuth out of individual servers entirely and into a single control plane that handles MCP authentication on behalf of all of them.
One OAuth implementation to maintain. One token store. One place to revoke access. One audit trail.
That’s the architecture shift worth understanding before you’re three MCP servers deep and rebuilding the same infrastructure for the third time. We’ll walk through exactly how it works in the next post.
Next in the series: The MCP Identity Sprawl Problem (And How to Solve It)
This post is part of Obot’s series on enabling MCP at enterprise scale. Obot is an open source MCP gateway that handles auth, access controls, and governance so your MCP servers don’t have to. Learn more at obot.ai.
