Enable Programmatic Authentication for MCP Servers Without Browser Redirects
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Domaine
- api, authentication, security
Piste de recherche
No implementation files, tests, or entry points are named. Start by reading the linked MCP Authorization Specification, RFC8414, and OAuth 2.0 for First-Party Applications draft; done would require identifying the target repository and agreeing how the optional metadata endpoint and challenge flow should be specified or implemented.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem Definition
Concrete Implementation Challenge: We are building a voice-based healthcare agent that needs to authenticate patients over phone calls. The current MCP OAuth specification requires browser-based redirects, which is impossible in a voice channel.
Validation: This affects any MCP implementation where:
- Users interact through voice (IVR systems, voice assistants)
- CLI tools need authentication without launching browsers
- Embedded devices without browser capabilities
Current Blocker
MCP specification mandates OAuth 2.1 with browser redirects:
Client -> Redirect to Authorization Endpoint -> Browser -> Callback
This flow cannot work when:
- No browser is available (phone calls)
- Browser interruption breaks user experience (CLI tools)
Minimal Proposed Change
Allow MCP servers to optionally support programmatic authentication by adopting the OAuth 2.0 for First-Party Applications specification:
- Add an optional field to Authorization Server Metadata (RFC8414):
{
"issuer": "https://mcp.example.com",
"authorization_endpoint": "https://mcp.example.com/authorize",
"authorization_challenge_endpoint": "https://mcp.example.com/authorize/challenge", // NEW
"token_endpoint": "https://mcp.example.com/token",
// ... other standard fields
}
- When
authorization_challenge_endpointis present, clients can use the challenge/response flow as defined in the First-Party Apps draft.
Why This Is Minimal
- Single metadata addition: Just one optional endpoint in server metadata
- Existing specification: Follows an established IETF draft rather than inventing new patterns
- Backwards compatible: Only active when server advertises the endpoint
- No protocol changes: Still uses authorization codes and standard token exchange
Security Considerations
Per the First-Party Apps specification:
- MUST only be used by first-party applications
- Authorization servers SHOULD restrict this endpoint to specific trusted client IDs
- All security requirements from Section 9 of the draft apply
Use Case Example
A voice agent could authenticate callers using knowledge-based authentication:
- Collect identity information (name, DOB, SSN last 4)
- POST to the challenge endpoint
- Receive authorization code
- Exchange for access token using standard flow
- Access MCP resources with the token
Alternative Considered
We considered using custom extensions, but that would fragment the ecosystem. Adopting an existing IETF draft enables broad use cases while maintaining compatibility.
Prototype
tell me which repo(s), if any, you want a protoytype created in, and I can make a PR.
References
- OAuth 2.0 for First-Party Applications Draft
- MCP Authorization Specification
- OAuth 2.0 Authorization Server Metadata (RFC8414)
Co authored by gregorySDTaylor and claude-sonnet-4
- Langage dominant
- MDX
- Étoiles
- 172
- Forks
- 56
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de modelcontextprotocol/ext-auth
-
Enterprise-Managed Authorization: say how the Resource Authorization Server gets the IdP's signing keysPeut-être pris @pcarleton l’a pris il y a 13 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
modelcontextprotocol/ext-auth#34 · 3 commentaires · 1 personne assignée ·
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
modelcontextprotocol/ext-auth#32 · 1 commentaire ·
-
DEBUGOuvertebug
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 10/100
-
Add Authorization Flow for MCP client server hosts extensionPeut-être pris @sberyozkin l’a pris il y a 195 jours. Ouverteenhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
modelcontextprotocol/ext-auth#26 · 1 commentaire ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 35/100
Toutes les issues de modelcontextprotocol/ext-auth
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
radix-ui/primitives#4228 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
-
Pull-through from gcr.io returns 500 when pulling using podman/buildahPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. OuverteIssue Triage-Needed
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
pulp/pulp_container#2581 ·
Les mainteneurs répondent en général sous 1 jour
-
[feart] 支持 MiMo 类型模型的关闭思考识别Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Batch RAG dry runs still initialize LightRAG and enter ingestionPeut-être pris @IlyaKhalafi l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
HKUDS/RAG-Anything#413 ·
Les mainteneurs répondent en général sous 3 jours