MCP + OAuth2.1 + AWS Cognito Example

What is MCP + OAuth2.1 + AWS Cognito Example?

This project demonstrates how to secure a Model Context Protocol (MCP) server using OAuth 2.1 authorization flows, implemented with Node.js and Express.js. It uses AWS Cognito as an example backing authorization server but is designed to be provider-agnostic, following the MCP Authorization Specification (version 2025-11-25).

How to use MCP + OAuth2.1 + AWS Cognito Example?

Clone the repository, install dependencies with npm run install:all, deploy AWS resources using npm run deploy, and start all services with npm run dev. Then visit http://localhost:3000 for the pre-registered client flow, http://localhost:3002 for the Dynamic Client Registration (DCR) flow, or http://localhost:3003 for the Client ID Metadata Document (CIMD) flow. Review generated .env files before running.

Key features of MCP + OAuth2.1 + AWS Cognito Example?

• Provider-agnostic OAuth 2.1 implementation (example uses AWS Cognito)
• Authorization Code flow with PKCE and RFC 8707 Resource Indicators
• Dynamic Client Registration (DCR) with API Gateway and Lambda
• Client ID Metadata Documents (CIMD) support via an authorization proxy
• Protected Resource Metadata (PRM) document discovery
• Three client implementations: static, auto-discovery (DCR), and metadata (CIMD)

Use cases of MCP + OAuth2.1 + AWS Cognito Example?

• Secure an MCP server with standard OAuth 2.1 flows and token validation
• Integrate any OAuth 2.1 compliant authorization server (e.g., Okta, Auth0)
• Automatically register clients without manual configuration via DCR
• Enable zero-config client registration using CIMD with URL‑based client IDs
• Test and compare OAuth 2.1 client registration methods in a development environment

FAQ from MCP + OAuth2.1 + AWS Cognito Example

What is the difference between DCR and CIMD?

Dynamic Client Registration (DCR) lets clients register with the authorization server at runtime via an API endpoint. Client ID Metadata Documents (CIMD) allow a client to use an HTTPS URL as its client_id; the authorization server fetches the metadata document from that URL, avoiding pre‑registration entirely.

Does this work with other authorization servers besides AWS Cognito?

Yes. The implementation is provider‑agnostic and follows OAuth 2.1 standards, so any compliant authorization server (e.g., Okta, Auth0) can be used as the backend.

What are the prerequisites to run this project?

Node.js 18+, an AWS test account with Cognito, API Gateway, Lambda, and DynamoDB, and basic knowledge of OAuth 2.1 flows.

How does the CIMD authorization proxy work?

When a client presents a URL‑based client_id, the MCP server fetches the client’s metadata document, transparently creates a Cognito app client via the DCR infrastructure, and forwards the OAuth request to Cognito. All bridging is handled server‑side.

What security measures are included for CIMD?

The proxy enforces SSRF protection (blocks private IP ranges, requires HTTPS in production), strict client_id validation