OAuth 2.1 mit Dynamic Client Registration

Worum es geht

Klassische OAuth-Setups verlangen eine vorab konfigurierte Client-Anwendung: Client-ID, Client-Secret und eine fest hinterlegte Redirect-URI. Für Custom Connectoren in Browser-KI ist das unpraktisch, weil die Anwendung erst beim Hinzufügen durch die Nutzerin entsteht. Die IETF hat dafür RFC 7591 spezifiziert: Der Client registriert sich beim Authorization-Server dynamisch zur Laufzeit. knowmind erlaubt das ausschließlich für Custom Connectoren mit Redirect-URIs aus einer Allowlist MCP-fähiger Plattformen.

Sequenz im Detail

1. Discovery: Der Connector liest die OAuth-Discovery-Metadaten unter /.well-known/oauth-authorization-server. knowmind antwortet mit allen Endpoints, unterstützten Grant-Types und der PKCE-Anforderung S256.
2. Registrierung: Der Connector ruft POST /oauth/register mit seinem Namen und seinen Redirect-URIs. knowmind prüft die URIs gegen die Allowlist (siehe Tabelle unten), legt einen oauth_clients-Eintrag mit tenant_id = NULL an und gibt eine Client-ID zurück. Ein Client-Secret wird nicht erzeugt — Public Client mit PKCE.
3. Authorization-Request: Der Connector schickt die Nutzerin auf /oauth/authorize mit response_type=code, client_id, redirect_uri, scope, einem zufälligen state sowie einem code_challenge (Base64-URL-encoded SHA-256-Hash über den vom Connector lokal gehaltenen code_verifier) und code_challenge_method=S256.
4. Login und Zustimmung: Wenn die Nutzerin noch nicht angemeldet ist, leitet knowmind sie auf /signin um. Magic-Link in der Mailbox, Bestätigung, Rücksprung. Bei diesem ersten Authorize-Vorgang wird die tenant_id des oauth_clients-Eintrags fest auf den Tenant der eingeloggten Nutzerin gesetzt — spätere Authorize-Flows mit derselben Client-ID müssen denselben Tenant treffen.
5. Authorization-Code: knowmind erzeugt einen kurzlebigen Code (10 Minuten gültig), persistiert ihn mit code_challenge, redirect_uri, user_id und tenant_id, und leitet den Connector mit ?code=…&state=… zurück.
6. Token-Tausch: Der Connector ruft POST /oauth/token mit grant_type=authorization_code, dem erhaltenen Code, der ursprünglichen redirect_uri, seiner client_id und dem code_verifier auf. knowmind verifiziert PKCE (SHA-256 über code_verifier gleich code_challenge), konsumiert den Code und gibt einen normalen kmt_-Access-Token zurück, gültig 30 Tage.
7. MCP-Aufrufe: Bei jedem MCP-Aufruf trägt der Connector den Token im Authorization: Bearer kmt_…-Header. Die übliche Tenant-Isolation greift — der Token sieht ausschließlich den Tenant, den die Nutzerin beim Authorize-Vorgang autorisiert hat.

Allowlist der erlaubten Redirect-Hosts

knowmind akzeptiert nur Redirect-URIs auf folgenden Hosts (HTTPS Pflicht, Ausnahme localhost für Entwicklung):

Subdomain-Matching: *.claude.ai wird akzeptiert, beispielsweise connectors.claude.ai. Andere Redirect-Hosts werden mit HTTP 400 und error: invalid_redirect_uri abgelehnt. Wer eine eigene Plattform anbinden möchte, beantragt die Aufnahme über info@schuebeler-consulting.de.

Tenant-Bindung beim ersten Login

Wenn ein Connector frisch registriert ist (per /oauth/register), kennt knowmind noch keinen Tenant — der Client-Eintrag trägt tenant_id = NULL. Beim ersten Authorize-Flow wird die tenant_id auf den Tenant der eingeloggten Nutzerin verdrahtet und ist danach unveränderlich. Versucht eine zweite Nutzerin desselben Connectors, sich mit einem anderen Tenant zu authentifizieren, antwortet knowmind mit HTTP 403 access_denied und der Hinweis-Meldung „Dieser OAuth-Client gehört zu einem anderen Arbeitsbereich".

Praktische Folge: Jede Nutzerin, die einen Custom Connector neu hinzufügt, durchläuft eine eigene DCR-Registrierung. Verschiedene Nutzerinnen desselben Tenants teilen sich nicht denselben Client-Eintrag.

Sicherheitsaspekte

• PKCE ist Pflicht. knowmind weist Authorize-Anfragen ohne code_challenge oder mit code_challenge_method ≠ S256 mit HTTP 400 ab. Damit ist der Authorization-Code gegen Abfangen über offene Redirects oder kompromittierte Browser-Erweiterungen geschützt.
• Keine Client-Secrets. token_endpoint_auth_method = none. Public Client mit PKCE ersetzt das klassische Client-Secret. Damit ist die Vorab-Verteilung von Geheimnissen an Browser-Anwendungen unnötig.
• Kurze Token-Laufzeiten. Access-Tokens leben 30 Tage, werden danach vom Connector über den Refresh-Pfad erneuert (Authorization Code Grant wird wiederholt durchlaufen, weil Refresh-Tokens im Standard-Flow nicht ausgegeben werden — der Connector startet den Authorize-Vorgang automatisch erneut).
• Widerruf jederzeit. Im Cockpit unter OAuth-Clients sehen Sie jeden registrierten Connector und können die Verbindung mit einem Klick widerrufen. Der Token wird sofort ungültig.
• State-Parameter Pflicht für CSRF-Schutz. Der Connector setzt einen zufälligen state, knowmind spiegelt ihn beim Redirect zurück. Der Connector prüft die Übereinstimmung, sonst wird der Code verworfen.