Verbindungen & Authentifizierung

Eine Verbindung speichert die Zugangsdaten eines Benutzers für einen MCP-Server. Server-Besitzer konfigurieren die Authentifizierung; jeder Benutzer verbindet sich einmal und nutzt die Verbindung in allen Unterhaltungen weiter.

Authentifizierungsmethoden

Wählen Sie die Methode in Schritt 3 des Serverformulars:

None — der Server ist offen — keine Verbindung nötig.
API Key — jeder Benutzer hinterlegt einen persönlichen Schlüssel, der als HTTP-Header mit jeder Anfrage gesendet wird.
OAuth 2.0 (Advanced) — Benutzer melden sich über den Zustimmungsbildschirm des Anbieters an; QAnswer speichert und erneuert die Tokens. Erfordert Client-ID, Client-Secret, Scopes sowie Authorization- und Token-URI.

Das Dropdown der Authentifizierungsmethoden mit None, OAuth 2.0 (Advanced) und API Key

API-Schlüssel-Konfiguration

Legen Sie mit dem Header-Name-Preset fest, wie der Schlüssel übertragen wird:

Bearer token — Authorization: Bearer Ihr-Schlüssel — das gängigste Schema.
X-API-Key — sendet den Schlüssel unverändert im Header X-API-Key.
x-litellm-api-key — für Deployments mit LiteLLM-Proxy.
Custom — definieren Sie eigenen Header-Namen und Wertvorlage.

Benutzerdefinierte Header-Konfiguration

Header-Name — ein beliebiger HTTP-Header, z. B. X-Weather-Key.
Wertvorlage — wie der Schlüssel eingebettet wird, z. B. Bearer {api_key}. Leer lassen, um den Schlüssel unverändert zu senden.

Endbenutzer-Formular

Passen Sie das Eingabefeld an, das Benutzer beim Verbinden sehen: Anzeigename, Platzhalter und ein Hilfetext, der sagt, wo der Schlüssel zu finden ist.

Regel für die Wertvorlage

Eine nicht leere Wertvorlage muss den Platzhalter {api_key} enthalten — er wird zur Laufzeit durch den Schlüssel des Benutzers ersetzt.

Benutzerdefinierte Header

Schritt 4 des Serverformulars fügt jeder MCP-Anfrage zusätzliche HTTP-Header hinzu. Zwei Tabs decken zwei Situationen ab:

All Users — feste Name/Wert-Paare, die für alle gesendet werden. Legen Sie hier niemals Secrets oder persönliche Tokens ab.
Per User — Felder, die jeder Benutzer beim Erstellen seiner Verbindung ausfüllt; der Wert wird als Header gesendet (Header-Key = Feldname).

Jedes Pro-Benutzer-Feld definiert:

Header-Name — wird unverändert als HTTP-Header-Key verwendet, z. B. X-Account-Id.
Anzeigename — die Beschriftung, die Benutzer im Verbindungsdialog sehen.
Typ — Plain (sichtbar) oder Secret (maskiert und sicher gespeichert).
Pflichtfeld — Pflichtfelder müssen ausgefüllt sein, bevor die Verbindung erstellt werden kann.

Der Tab Per User mit einem Feld X-Account-Id und seinem Editor

Sicherheit

Verwenden Sie Secret für alles Sensible — Werte werden in der Oberfläche maskiert und verschlüsselt gespeichert. All-Users-Header sind für jeden Bearbeiter des Servers sichtbar und gehen mit jeder Anfrage mit: keine Zugangsdaten dort ablegen.

Was Endbenutzer sehen

Fügt ein Benutzer eine Verbindung hinzu — über die Serverseite oder auf Aufforderung im Chat — erfasst ein Dialog genau das, was Sie konfiguriert haben: das API-Schlüssel-Feld plus Ihre Pro-Benutzer-Felder.

Der Add-Connection-Dialog fragt nach Weather API Key und Account ID

Bestehende Verbindungen werden auf der Serverseite gelistet, wo Benutzer sie auch löschen können:

Das Verbindungen-Panel mit einer aktiven Verbindung

Hinweise zu OAuth 2.0

Benutzer werden zum Zustimmungsbildschirm des Anbieters geleitet und kehren genau zur Ausgangsseite zurück.
Stirbt ein Refresh-Token, wird die gespeicherte Verbindung entfernt und der Chat bittet um erneutes Verbinden.
Das Löschen einer Verbindung in QAnswer widerruft nicht die Freigabe beim Anbieter — erledigen Sie das in dessen Sicherheitseinstellungen.

Zurück

MCP-Server hinzufügen

Weiter

Administration