How MCP Leverages OAuth 2.1 and RFC 9728 for Authorization

Authorization isn’t just a checkbox in agentic systems. It’s a make-or-break layer for security, scalability, and trust. Without a clear way to authenticate dynamically, AI agents either hit brittle, hardcoded APIs or introduce serious security gaps. That’s why authorization has been one of the biggest missing pieces in the Model Context Protocol (MCP).

When MCP was first introduced, it focused on helping AI agents interact with APIs. But it left out that one critical capability: authorization. For the past six months, the MCP team has been working to change that, building a secure, dynamic authorization layer that can keep up with the unpredictable nature of agentic systems.

The new MCP authorization model is based on OAuth 2.1, as expected. But it also adds an important enhancement: support for RFC 9728 (OAuth 2.0 Protected Resource Metadata), a long-overlooked spec that turns out to be essential for the way agentic AI systems actually behave.

Agentic Tools Are Not Like Regular Function Calls

In traditional applications, developers directly program which APIs to call. This is known as direct invocation. The software knows exactly which API endpoint it needs ahead of time, and the location of the authorization server can be manually configured.

Agentic AI tools work differently. Instead of following fixed paths, agents are dynamically assigned MCP tools at runtime, and these tools interact with various APIs. At runtime, through inferred invocation, agents determine which tools to use based on goals, user prompts, or evolving context, without knowing beforehand which APIs will be accessed.

Because of this dynamic behavior, agents cannot predict in advance which APIs they will call or which authorization servers they will need. Hardcoding this information is impractical; agents must be able to discover authorization details automatically as they operate.

The Need for Dynamic Authorization

Most early MCP use cases assumed preconfigured trust between clients and tools, an unrealistic assumption in enterprise environments. As agentic architectures became more dynamic and open-ended, the need for runtime authorization discovery became clear.

OAuth 2.1 provided the base, but it wasn’t enough on its own. Without a way for APIs to advertise how they expect to be accessed, agents still couldn’t operate autonomously. RFC 9728 addresses this need. Over eight years in the making, RFC 9728 was developed long before the rise of large language models and agentic AI. Initially seen as a useful enhancement for traditional apps, it has now become essential for enabling dynamic, AI-driven integrations.

The Importance of RFC 9728

RFC 9728 allows APIs to publish information about how they expect to be accessed securely. When an agent tries to call an API without a valid access token, the API sends back a response that includes a link to this information.

From there, the agent can learn which authorization servers it should contact to get permission, what types of permissions it needs to ask for, and how to make sure the access token it gets will be accepted by the API. This dynamic process allows agents to connect to APIs safely and automatically, even when everything is happening on the fly.

MCP’s New Authorization Model

The updated MCP specification builds on OAuth 2.1, strengthened by RFC 9728. This ensures that AI agents can discover trusted authorization servers, obtain access tokens securely, and interact with APIs they encounter through dynamically assigned tools.

Without RFC 9728, MCP agents would require hardcoded server details, undermining the goal of dynamic, autonomous operation. With RFC 9728, MCP provides a modern, secure framework for agents to adapt and thrive.

A New Era for Authorization

The finalization of RFC 9728 comes at a perfect moment. As agentic AI systems grow more complex, static assumptions about authorization no longer hold. Agents need the ability to discover how APIs expect to be accessed, and respond in real time.

By adopting OAuth 2.1 alongside RFC 9728, MCP now provides a secure framework for this kind of dynamic behavior. In this new, interconnected landscape, AI agents can request tokens, discover auth servers, and interact with tools on the fly.

Why This Matters for Developers

For developers, the integration challenge is real, especially when working with AI agents that need to access multiple APIs securely and autonomously. Every new API could mean a new token setup or a different auth config.

With MCP’s updated authorization model, that friction disappears. Agents can now use standardized metadata to securely authenticate at runtime, without advance configuration. That means you can generate, deploy, and call tools without worrying about how your agents will handle auth across different systems.

What’s Next

The new MCP authorization model is a major milestone, but it’s just the beginning. The next challenge is making this seamless for developers: turning RFC 9728 from spec into practice, and abstracting away the complexity so agents can authenticate tools without added friction.

At Gentoro, we’re building toward that future. Our OpenAPI tool generation feature lets you turn any OpenAPI spec into a set of MCP-compliant agentic tools. If you’d like to try check it in our playground, sign up for the beta or request a full demo. We’d love to hear from you!

TL;DR

• Until now, authorization has been a missing piece for MCP
• OAuth 2.1 and RFC 9728 give MCP the dynamic authorization model agents need
• RFC 9728 lets APIs expose how they expect to be accessed, so agents can request tokens in context
• Hardcoding auth flows is no longer necessary
• RFC 9728 is key to enabling scalable, secure AI integrations and OpenAPI-based agentic tools
• Gentoro uses this model to support dynamic, composable tool workflows without vendor lock-in