SEP-2059: OAuth Device Flow for stdio MCP Servers#2059
SEP-2059: OAuth Device Flow for stdio MCP Servers#2059SamMorrowDrums wants to merge 7 commits intomodelcontextprotocol:mainmodelcontextprotocol/modelcontextprotocol:mainfrom SamMorrowDrums:sep-stdio-oauth-device-flowSamMorrowDrums/modelcontextprotocol:sep-stdio-oauth-device-flowCopy head branch name to clipboard
Conversation
This SEP proposes a standardized mechanism for stdio-based MCP servers to perform OAuth authentication using the OAuth 2.0 Device Authorization Grant (RFC 8628). Key features: - Ephemeral tokens issued at runtime (no persistent storage) - Device flow via tools, tools/list_changed, and URL elicitation - Alternative lazy auth pattern (auth on first tool call) - CIMD passthrough from host applications - SDK-level implementation (server authors just opt-in) - Scope challenge support for step-up authorization Reference implementation: github/github-mcp-server#1649
|
@SamMorrowDrums at a high level, I am curious why this is necessary in STDIO cases. A MCP server that runs locally has access to any authentication/authorization library - that is, if I run GitHub STDIO server, I can just use either a GitHub-specific auth library or rely on a generic OAuth implementation. When a tool is invoked, the tokens can be dynamically pulled from the cache, passed to the downstream API, and then if there is an error, the tool can trigger an interactive flow that is completely detached from what flow needs to be used here. My worry here is that we're implementing a bunch of custom stuff for STDIO, and on top of that - it's Device Code Flow, which is highly phishable and likely not something we'd necessarily want to promote as the de-facto auth modality. |
|
That makes sense @localden mostly what I want is to move PAT users off hard coding tokens in stdio and I am not sure of a simple way to do it.
At minimum there needs to be a way to handle discovery and token delivery via stdio. If using CIMD wouldn't have to support device flow at all. |
Summary
This SEP proposes a standardized mechanism for stdio-based MCP servers to perform OAuth authentication using the OAuth 2.0 Device Authorization Grant (RFC 8628).
Problem Statement
The current MCP Authorization specification explicitly states that stdio transport implementations "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." This has led to widespread use of Personal Access Tokens (PATs) stored in plaintext configuration files, creating security and usability problems.
No existing SEP addresses this gap. The closest related work focuses on different concerns:
Proposed Solution
auth_logintool: Uses RFC 8628 for browserless OAuthtools/list_changednotifications: Dynamic tool registration after authPrior Art & Community Demand
Demo
Why This Needs a SEP
Why Not Host-Driven OAuth?
The host can't drive OAuth because it would need to know each server's authorization server:
github.comslack.comcorp.okta.comThis doesn't scale. CIMD solves the identity problem (host passes its identity URL), but the server must drive the OAuth flow because only it knows its authorization server.
Key Features
auth_logintool (or all tools with lazy auth)docker run --rm)Open Questions
initializephase?Seeking Sponsor
This SEP is seeking a sponsor from the MCP core maintainers.
Status: Draft
Type: Standards Track
Author: @SamMorrowDrums