Security & Autorisierung: Vertrauensketten für MCP
Ein Token kann korrekt signiert und trotzdem für den falschen Server bestimmt sein. Ohne Resource- und Audience-Bindung wird aus Delegation ein wiederverwendbarer Generalschlüssel — selbst wenn PKCE und Consent sauber aussehen.
Fortgeschritten · ~25 Min · 11 Abschnitte Einführung · 9 Übungen (davon 2 Missionen)
Modul starten →
Fortschritt wird gespeichert — du kannst das Modul später jederzeit fortsetzen.
Das kannst du danach
- ✓Protected Resource und Authorization Server kontrolliert entdecken und binden
- ✓Client-Metadaten, Redirect, State und PKCE als zusammenhängenden Flow absichern
- ✓Audience, Scopes, Fachautorisierung und Secret-Lifecycle serverseitig durchsetzen
Übungen
- 1. EntscheidungWas ist der korrekte nächste Schritt des Clients?
- 2. EntscheidungWie wird der Zugriff korrekt delegiert?
- 3. EntscheidungWie sollte der Host reagieren?
- 4. EntscheidungWelche Validierungsregel ist richtig?
- 5. EntscheidungWelche Registrierungsstrategie ist angemessen?
- 6. EntscheidungWelche Autorisierungsstrategie begrenzt Delegation sinnvoll?
- 7. EntscheidungWie sollte der Integrationsfluss stattdessen gestaltet werden?
- 8. DiagnoseMission: Ein gültiges Token am falschen Server
- 9. ReihenfolgeSequence Quest: Token nur für die richtige Resource
Arbeitsartefakte
- ↓Sequence Quest: Token nur für die richtige Resourcemcp-auth-sequence-2026-09-05 · geprüft: 2026-09-05
Quellen & Aktualität9 Primärquellen · zuletzt geprüft:
- 01modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- 02modelcontextprotocol.io/specification/2026-07-28/basic/index
- 03modelcontextprotocol.io/specification/2026-07-28/server/tools
- 04modelcontextprotocol.io/specification/2026-07-28/deprecated
- 05rfc-editor.org/rfc/rfc8707
- 06rfc-editor.org/rfc/rfc7636
- 07rfc-editor.org/rfc/rfc8252
- 08rfc-editor.org/rfc/rfc9728
- 09modelcontextprotocol.io/specification/2026-07-28/client/elicitation
Verfasst von Julian Zentgraf