NapthaAI/http-oauth-mcp-server

## Introduction
This repo provides a reference implementation for creating a remote MCP server that supports the Streamable HTTP & SSE Transports, authorized with OAuth based on the MCP specification.
Note that the MCP server in this repo is logically separate from the application that handles the report SSE + HTTP transports, and from OAuth.
As a result, you can easily fork this repo, and plug in your own MCP server and OAuth credentials for a working SSE/HTTP + OAuth MCP server with your own functionality.
> But, why?
Great question! The MCP specification added the authorization specification based on OAuth on March 25, 2025. At present, as of May 1, 2025:
The Typescript SDK contains many of the building blocks for accomplishing an OAuth-authorized MCP server with streamable HTTP, but there is no documentation or tutorial on how to build such a server
The Python SDK contains neither an implementation of the streamable HTTP transport, nor an implementation of the OAuth building blocks that are present in the typescript SDK
The Streamable HTTP transport is broadly unsupported by MCP host applications such as Cursor and Claude desktop, though it may be integrated directly into agents written in JavaScript using the JS/TS SDK's StreamableHttpClientTransport class
At Naptha AI, we really wanted to build an OAuth-authorized MCP server on the streamable HTTP transport, and couldn't find any reference implementations, so we decided to build one ourselves!
## Dependencies
Bun, a fast all-in-one JavaScript runtime, is the recommended runtime and package manager for this repository. Limited compatibility testing has been done with npm + tsc.
## Overview
This repository provides the following:
1. An MCP server, which you can easily replace with your own
2. An express.js application that manages both the SSE and Streamable HTTP transports and OAuth authorization.
This express application is what you plug your credentials and MCP server into.
Note that while this express app implements the required OAuth endpoints including /authorize and the Authorization Server Metadata endpoint (RFC8414), it does not implement an OAuth authorization server!
This example proxies OAuth to an upstream OAuth server which supports dynamic client registration (RFC7591). To use this example, you will need to bring your own authorization server. We recommend using Auth0; see the "Setting up OAuth" Section below.
## Configuring your server
### Notes on OAuth & Dynamic Client Registration
To use this example, you need an OAuth authorization server. Do not implement this yourself! For the purposes of creating our demo, we used Auth0 -- this is a great option, though there are many others.
The MCP specification requires support for an uncommon OAuth feature, specifically RFC7591, Dynamic Client Registration. The MCP specification specifies that MCP clients and servers should support the Dynamic client registration protocol, so that MCP clients (whever your client transport lives) can obtain Client IDs without user registration. This allows new clients (agents, apps, etc.) to automatically register with new servers. More details on this can be found in the authorization section of the MCP specification, but this means that unfortunately, you cannot simply proxy directly to a provider like Google or GitHub, which do not support dynamic client registration (they require you to register clients in their UI).