Folgefeature: Standardkonforme OAuth-2.1-Autorisierung für Remote-MCP #15

Open
opened 2026-07-17 09:06:18 +02:00 by frank · 0 comments
Owner

Folgeissue zu #11 und Teil der Sicherheits-Roadmap aus #1. Kein Blocker für einen ausschließlich lokalen oder hinter einem vertrauenswürdigen Gateway betriebenen MVP.

Ziel

Port 9334 kann als Remote-MCP-Endpunkt standardkonform autorisiert betrieben werden, ohne eine proprietäre Token-Lösung oder Token-Passthrough.

Scope

  • MCP-Server als OAuth-2.1 Resource Server integrieren.
  • OAuth 2.0 Protected Resource Metadata nach RFC 9728 bereitstellen.
  • WWW-Authenticate mit resource_metadata und passenden Scopes.
  • Autorisierungsserver über RFC 8414 beziehungsweise OpenID Connect Discovery bekannt machen.
  • Access Tokens vollständig validieren: Signatur, Issuer, Expiry, Audience/Resource und Scopes.
  • Ausschließlich Tokens akzeptieren, die spezifisch für diesen MCP-Server ausgestellt wurden.
  • Kein Passthrough eingehender MCP-Tokens an Ziel-Webservices.
  • Least-Privilege-Scopes mindestens getrennt für read-only und allgemeine HTTP-Requests entwerfen.
  • TLS für alle nicht-lokalen Endpunkte.
  • Sichere Caches, Token-Redaction und kurze Fehlerantworten ohne Token-Details.
  • Kompatibilität mit dem offiziellen Go SDK und üblichen MCP-Clients testen.

Akzeptanzkriterien

  • Ein standardkonformer MCP-Client entdeckt Resource- und Authorization-Metadaten und kann den Flow durchführen.
  • Fehlende, abgelaufene, falsch signierte oder für eine andere Audience ausgestellte Tokens werden abgelehnt.
  • Scope-Prüfung trennt http_get und http_request.
  • Tests bestätigen, dass eingehende Tokens nie in den privaten Tunnel oder an Zielserver gelangen.
  • Deployment- und Autorisierungsfluss sind im Wiki dokumentiert.
  • Eine Security-Review der OAuth-Konfiguration ist vor Freigabe erfolgt.

Referenzen

Folgeissue zu #11 und Teil der Sicherheits-Roadmap aus #1. Kein Blocker für einen ausschließlich lokalen oder hinter einem vertrauenswürdigen Gateway betriebenen MVP. ## Ziel Port 9334 kann als Remote-MCP-Endpunkt standardkonform autorisiert betrieben werden, ohne eine proprietäre Token-Lösung oder Token-Passthrough. ## Scope - MCP-Server als OAuth-2.1 Resource Server integrieren. - OAuth 2.0 Protected Resource Metadata nach RFC 9728 bereitstellen. - WWW-Authenticate mit resource_metadata und passenden Scopes. - Autorisierungsserver über RFC 8414 beziehungsweise OpenID Connect Discovery bekannt machen. - Access Tokens vollständig validieren: Signatur, Issuer, Expiry, Audience/Resource und Scopes. - Ausschließlich Tokens akzeptieren, die spezifisch für diesen MCP-Server ausgestellt wurden. - Kein Passthrough eingehender MCP-Tokens an Ziel-Webservices. - Least-Privilege-Scopes mindestens getrennt für read-only und allgemeine HTTP-Requests entwerfen. - TLS für alle nicht-lokalen Endpunkte. - Sichere Caches, Token-Redaction und kurze Fehlerantworten ohne Token-Details. - Kompatibilität mit dem offiziellen Go SDK und üblichen MCP-Clients testen. ## Akzeptanzkriterien - Ein standardkonformer MCP-Client entdeckt Resource- und Authorization-Metadaten und kann den Flow durchführen. - Fehlende, abgelaufene, falsch signierte oder für eine andere Audience ausgestellte Tokens werden abgelehnt. - Scope-Prüfung trennt http_get und http_request. - Tests bestätigen, dass eingehende Tokens nie in den privaten Tunnel oder an Zielserver gelangen. - Deployment- und Autorisierungsfluss sind im Wiki dokumentiert. - Eine Security-Review der OAuth-Konfiguration ist vor Freigabe erfolgt. ## Referenzen - MCP Authorization 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization - MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices - RFC 9728: https://www.rfc-editor.org/rfc/rfc9728.html - RFC 8707 Resource Indicators: https://www.rfc-editor.org/rfc/rfc8707.html - OAuth 2.0 Security Best Current Practice, RFC 9700: https://www.rfc-editor.org/rfc/rfc9700.html
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
ai-tools/private-proxy-mcp#15
No description provided.