Building Secure AI Contexts: Hands-On with MCP Authorization, OAuth 2.1, and AWS Cognito
AI Security & Development
As AI systems grow more autonomous, our security frameworks must keep pace. Today’s AI agents aren’t confined to a few known APIs, they explore, authenticate, and operate across unpredictable environments, in real time. Traditional OAuth setups, designed for tightly connected applications, simply don’t scale for this.
That’s why new protocols like Model Context Protocol (MCP) Authorization and OAuth 2.0 Protected Resource Metadata (RFC 9728) have emerged. They rethink how authorization works in a dynamic, agent-driven world.
In this post, I’ll walk you through why these changes matter, how they transform agent-to-API security, and how we built a proof-of-concept using MCP Authorization, OAuth 2.1, and AWS Cognito.
Why OAuth Needed an Upgrade
Originally, OAuth 2.0 helped break down application silos by separating authentication and authorization. Apps could finally talk to each other via APIs. But this introduced a catch: applications had to hardcode their Authorization Servers, relying on providers like Google or Microsoft.
In a world of agentic AI, this model falls apart. Agents need to connect with thousands of APIs dynamically, without preconfigured trust relationships. Manually setting up every API isn’t realistic.
We need a system where agents can discover which Authorization Server to use and establish secure access, on the fly.
That’s the problem MCP Authorization and RFC 9728 solve.
Meet MCP Authorization and RFC 9728
Both were finalized in April 2025, marking a major shift for AI integrations.
MCP Authorization Specification separates the Resource Server (which hosts the data) from the Authorization Server (which issues access tokens).
The Resource Server shares a Protected Resource Metadata (PRM) document, listing trusted Authorization Servers.
Here’s how it works in practice (defined in RFC 9728):
Client requests a protected resource.
Resource Server replies with a
401 Unauthorizedand a WWW-Authenticate header pointing to the PRM.Client fetches the PRM, finds the correct Authorization Server.
Client initiates an OAuth 2.1 Authorization Code flow with PKCE.
Once authorized, the client gets an access token and can request the resource.
This removes hardcoded dependencies and scales securely across diverse agent ecosystems.
Our Proof-of-Concept: MCP Server + OAuth 2.1 + AWS Cognito
To show how this works, we built a proof-of-concept (POC) connecting an MCP server to AWS Cognito as the Authorization Server.
Architecture:
MCP Server (Resource Server):
Built with Node.js (Express.js).
Serves a
.well-known/oauth-protected-resourceendpoint.Validates access tokens for protected APIs.
AWS Cognito (Authorization Server):
Handles OAuth 2.1 Authorization Code flow with PKCE.
Issues JWTs for secure client authentication.
MCP Client:
Discovers Authorization Server via PRM.
Handles token exchange and authenticated requests.
High-Level Flow:
Discovery:
Client requests a resource.
MCP Server responds with
401 + WWW-Authenticate.Client retrieves PRM document.
Authorization:
Client identifies Cognito as the Authorization Server.
Redirects user to Cognito’s UI for login.
Client receives authorization code.
Token Exchange:
Client exchanges code (with PKCE) for access token.
Authenticated Requests:
Client uses Bearer token to access protected resource.
MCP Server validates token before granting access.
Why This Matters for AI Security
Autonomous AI agents must connect to external APIs for tasks like data enrichment and execution. Securing these interactions requires:
Dynamic Discovery: Find authorization paths at runtime.
Minimal Pre-Configuration: No need for manual API setups.
Interoperability: Standardized flows ensure smooth integration.
Proof-of-Access: Tokens and JWTs provide traceable, auditable access.
MCP Authorization delivers this flexibility and trust.
Next Step: Dynamic Client Registration (DCR)
Our POC handles discovery and token exchange. We’ve also added Dynamic Client Registration (DCR) to the POC. Since AWS Cognito doesn’t natively support DCR, we built a custom /register endpoint. This lets agents register dynamically at runtime, aligning with RFC 7591.
Static vs Dynamic Clients after Auth:
Static Client: Registered manually.
Dynamic Client: Registered automatically via DCR.
This brings the POC fully in line with modern AI security standards.
Cognito App clients:
Static Client after auth;
Dynamic Client after auth and register;
Best Practices: Building Secure AI Contexts
Here are key takeaways for teams building agentic AI security:
✅ Separate Resource Servers and Authorization Servers.
✅ Use Protected Resource Metadata for dynamic discovery.
✅ Follow OAuth 2.1 Authorization Code flow with PKCE.
✅ Plan for Dynamic Client Registration in your roadmap.
For code examples and setup instructions, check out our GitHub repository:
👉 MCP OAuth2 AWS Cognito Example
🔹 Want the full deep dive? Check out my full article on Medium.
🚀 Stay tuned for more posts in AI Security & Development! Follow for more insights on securing AI, cloud, and Web3.
AI Security & Development - AI table of contents included.
Building Secure AI Contexts: Hands-On with MCP Authorization, OAuth 2.1, and AWS Cognito