Note: This post discusses our experience implementing MCP with OAuth 2.0 at Altertable. While we reference the MCP specification and OAuth standards, some implementation details and timeline claims are based on our understanding and may evolve as the standards mature.
When the Model Context Protocol (MCP) appeared in 2024, it promised to make AI systems interoperable: a common layer where models, tools, and data platforms could talk using JSON-RPC.
Early versions of MCP delivered on that promise, but only locally. The standard transport was stdio: a client would spawn a server as a subprocess and communicate via standard input/output. It was elegant, fast, and secure by isolation: perfect for local copilots or IDE extensions.
But as soon as people tried to build shared or cloud-hosted MCP servers, the model broke down. Each client-server pair was ephemeral and one-to-one. There was no concept of persistent identity, authentication, or session continuity. MCP needed to evolve from a local IPC trick into a true network protocol.
The End of Locality
The stdio model was great for experimentation but poor for distribution. It hard-coded locality into the protocol.
As adoption grew, the pain points became obvious:
- No way to identify or authorize clients
- No persistent sessions or tokens
- No multi-tenant security model
Developers started grafting HTTP wrappers and API key systems onto MCP — clever, but inconsistent. The ecosystem needed a shared identity layer, and it arrived this year.
OAuth 2.0 Comes to MCP
The MCP Authorization spec (as of 2025) introduced OAuth 2.0 as the official framework for authentication and delegated authorization.
That brought MCP into line with modern web identity systems. Instead of subprocesses that “just trust” the client, MCP servers can now expose endpoints for secure, consent-based, scoped token flows — the same machinery used by modern APIs.
It's what turns MCP from “local JSON-RPC” into something business-ready.
Dynamic Client Registration: The Key Upgrade
The biggest unlock comes from Dynamic Client Registration (DCR) — RFC 7591.
In classic OAuth, every client has to be pre-registered with a fixed ID and secret. That's fine for a few integrations, but not when hundreds of AI agents want to talk to hundreds of MCP servers.
DCR fixes that by letting clients register themselves securely at runtime.
A compliant MCP server exposes various endpoints to:
- Discover the server's OAuth metadata
- POST its registration details (redirect URIs, scopes, grant types)
- Receive unique credentials from the server
- Continue with a normal OAuth flow
Each client gets its own credentials and scopes — no shared keys, no manual onboarding.
How We Built It at Altertable
Disclaimer: This section describes our implementation approach at Altertable. We're sharing our experience building an MCP server with OAuth 2.0 and DCR support.
We implemented it using two open-source gems that fit perfectly into our Rails-based architecture:
-
Loading code...handles the OAuth 2.0 layer — issuing access tokens, managing client registration, and enforcing scopes. Its integration with ActiveRecord makes it straightforward to persist tokens and clients in our existing user system. We're not alone in this approach: companies like GitLab use similar Doorkeeper-based OAuth implementations with DCR compliance.
-
Loading code...provides a Rack-compatible MCP server implementation. It runs alongside our web stack, using the same routing and middleware infrastructure. That means every MCP tool has full access to the same domain models and authorization logic as our API.
Architecturally, this was a natural fit.
Our frontend already communicates with Rails through a GraphQL API, and each MCP tool mirrors those same operations — from querying user data to triggering analyses.
By design, anything a human can do in the UI, an agent can do through MCP.
No parallel logic, no special SDKs — just two clients (human and agent) calling the same abstractions.
That symmetry has been a guiding principle since day one: everything is either user-driven or agent-driven, but it's the same product underneath.
Why It Matters
This architecture positions our platform as part of the next generation of AI-native infrastructure: systems that are both securely extensible and agent-accessible.
Instead of distributing static API keys or managing one-off integrations, external tools and agents can discover our platform, register dynamically, and interact through OAuth-scoped MCP sessions.
It's a small implementation detail with huge implications:
- No manual credential management
- First-class security and auditability
- Open interoperability with any compliant AI agent
The result: a platform that's ready not just for dashboards and queries, but for autonomous collaboration across the emerging AI ecosystem.
From stdio to OAuth: MCP has grown up. This evolution represents a significant step toward making AI systems truly interoperable at scale.
