One sign-in for every MCP server you connect to
Updated 2026-09-28
You sign in once across several MCP servers when they all trust the same authorization server. Each server still issues its own scoped grant, so a shared sign-in doesn't mean shared access. Without that shared trust, each server runs its own login, because the MCP authorization spec treats every server as an independent protected resource with no built-in link to any other.
How does MCP authorization work?
An MCP client calls a server and gets a 401 back with a WWW-Authenticate header pointing to that server's protected resource metadata (RFC 9728). That document names the server's authorization server. The client reads the authorization server's own metadata (RFC 8414) to find its endpoints, registers itself there on the spot through dynamic client registration (RFC 7591) since nobody set up a client id in advance, and opens the authorization endpoint with a PKCE code challenge (RFC 7636) instead of a client secret. The person signs in, sees what the client wants to reach, and approves it. The client exchanges the resulting code, with its PKCE verifier, for a token scoped to that one server. The full sequence is set out in the MCP authorization specification and the OAuth 2.1 draft it builds on.
Why does each server usually mean a separate sign-in?
Because RFC 9728 binds a protected-resource document, and the token issued against it, to one resource. Two MCP servers built by different teams normally run two separate authorization servers, or at least two separate client registrations and consent screens, even when the same person is signing in to both. Each server keeps its own login page, its own session cookie, and its own consent screen, so a person repeats the login flow for every server they connect, even minutes apart on the same laptop.
What are the options?
One shared authorization server
Every resource server trusts the same issuer. A person signs in to that issuer once; each resource server still publishes its own protected-resource document and gets its own scoped token from the shared issuer. Adding a second server only asks for consent, not a new login, because the browser already holds a session with the issuer.
An MCP gateway
One proxy sits in front of many servers. A person signs in to the gateway once, and the gateway holds its own credentials to each server behind it. This is simple from the client's side. But the gateway becomes the one place holding every credential, and a compromise there reaches every server behind it.
Per-server accounts
Each server runs its own authorization server and its own accounts. This is the simplest thing to build for one server, and the worst thing to use across many: a person collects a new sign-in, and often a new account and password, for every additional server they connect.
| Option | Sign-ins needed | Revoking one app |
|---|---|---|
| Shared authorization server | One, then consent per app | Possible without touching the rest, if tokens are scoped per app |
| Gateway | One, to the gateway | Depends on the gateway; it holds every downstream credential |
| Per-server accounts | One per server | Simple, but so is everything else about that server's account |
Checklist
- Does connecting to a second server ask only for consent, or does it run a whole new login?
- Is each token scoped to one resource, so a token minted for one server is refused by another?
- Does discovery happen on its own, through protected resource metadata, authorization server metadata, and dynamic client registration, or does a person have to hand-configure a client id for every server?
- Does the authorization server require PKCE with S256, not the weaker "plain" method?
- Can one app's access be revoked without signing the person out of every other app?
How Agent Rails does it
One account: a person signs in once with a code sent to their phone, and every app on Rails uses that same account. rails.so is the authorization server: one issuer, one document at /.well-known/oauth-authorization-server, PKCE required with S256 and nothing weaker, and open dynamic client registration so no app has to be added by hand. Each app runs on its own host with its own MCP server: Rolodex answers at rolodex.rails.so/mcp, and its own protected-resource document at /.well-known/oauth-protected-resource names rails.so as its authorization server, so discovery for a second app points back to the same issuer as the first.
Because the sign-in session from the first app is already there, connecting to a second app goes straight to the consent screen instead of a new phone code. Each grant becomes its own token, bound to the person's account, the one installation, and that one app. A token minted for one app is refused by another, and access to one app can be revoked without touching the rest.