OAuth login for remote MCP servers

Intent

This pattern assumes a remote MCP server behind an API gateway, and an identity provider your people already sign in with. It connects that provider to the OAuth flow MCP hosts already implement, and issues tokens that open the MCP server and nothing else. This enables three outcomes:

1. People sign in with the accounts and password rules they already have, with no new credentials to manage.
2. People rarely have to sign in again, because the host refreshes its own tokens.
3. A token leaked from an AI client can't reach the rest of your platform.

Motivation

Most remote MCP servers start with a token pasted into the AI client. That's reasonable for a demo, and it fails in production in two ways:

1. It doesn't last. Access tokens are short-lived by design, so people are left replacing them by hand.
2. It carries too much. A token issued for the platform grants everything the user can do across it, stored in a tool that only needed one route, against the principle of least privilege.

The MCP authorization specification makes the server an OAuth resource server, so a host can discover the login page, sign the user in and refresh the token itself. The server only has to describe itself, using protected resource metadata, and a dedicated scope turns "a valid user token" into "a token meant for this server".

Applicability

Use this pattern when:

1. A remote MCP server should know who each user is, using logins they already have.
2. The identity provider can't register MCP hosts automatically, or the hosts are a short, known list.
3. The token an MCP host holds must not open the rest of the platform.

Do not use this pattern when:

1. The server runs on the user's own machine, where the spec has hosts take credentials from the environment.

Structure

Participants

Constraints and trade-offs

1. Each AI client must be registered before it can connect, test tools included. That's a deliberate control, and it means adding a client takes a change and a deploy.
2. Adding your own claims to tokens puts code in the path of every sign-in. A fault there can stop everyone signing in, not only MCP users, so it deserves the care of any identity component.
3. Shorter-lived tokens pick up access changes sooner, at the cost of more refreshes and more calls to the provider.
4. A scope binds a token to a server rather than to one connection. That's safe while access follows the user, and binding it to one connection needs a provider that supports resource indicators.

Part of how I deliver

Login is part of the job on any remote MCP server I deliver, and this is the pattern I use for it. It's one of many I draw on through contract delivery, so your people sign in the way they already do, and the rest of the server's design can build on knowing who they are.

Related