Connexions & authentification
Une connexion stocke les identifiants d'un utilisateur pour un serveur MCP. Le propriétaire du serveur configure le mode d'authentification ; chaque utilisateur se connecte ensuite une fois et réutilise cette connexion dans toutes ses conversations.
Méthodes d'authentification
Choisissez la méthode à l'étape 3 du formulaire serveur :
- None — le serveur est ouvert — aucune connexion requise.
- API Key — chaque utilisateur fournit une clé personnelle, envoyée en en-tête HTTP à chaque requête.
- OAuth 2.0 (Advanced) — les utilisateurs se connectent via l'écran de consentement du fournisseur ; QAnswer stocke et rafraîchit les jetons. Nécessite client ID, client secret, scopes et les URI d'autorisation/jeton.
Configuration de la clé API
Choisissez comment la clé est transmise avec le préréglage Header Name :
- Bearer token — Authorization: Bearer votre-clé — le schéma le plus courant.
- X-API-Key — envoie la clé brute dans l'en-tête X-API-Key.
- x-litellm-api-key — pour les déploiements avec proxy LiteLLM.
- Custom — définissez votre propre nom d'en-tête et modèle de valeur.
Configuration d'en-tête personnalisée
- Nom d'en-tête — n'importe quel en-tête HTTP, p. ex. X-Weather-Key.
- Modèle de valeur — comment la clé est intégrée, p. ex. Bearer {api_key}. Laissez vide pour envoyer la clé brute.
Formulaire utilisateur
Personnalisez le champ que voient les utilisateurs à la connexion : libellé, placeholder et texte d'aide indiquant où trouver leur clé.
En-têtes personnalisés
L'étape 4 du formulaire serveur ajoute des en-têtes HTTP à chaque requête MCP. Deux onglets couvrent deux situations :
- All Users — paires nom/valeur fixes envoyées pour tout le monde. N'y mettez jamais de secrets ni de jetons personnels.
- Per User — champs que chaque utilisateur remplit à la création de sa connexion ; la valeur est envoyée en en-tête (clé = nom du champ).
Chaque champ par utilisateur définit :
- Nom d'en-tête — utilisé tel quel comme clé d'en-tête HTTP, p. ex. X-Account-Id.
- Nom affiché — le libellé que voient les utilisateurs dans le dialogue de connexion.
- Type — Plain (visible) ou Secret (masqué et stocké de façon sécurisée).
- Requis — les champs requis doivent être remplis pour créer la connexion.
Ce que voient les utilisateurs
Quand un utilisateur ajoute une connexion — depuis la page du serveur ou quand le chat le lui demande — un dialogue collecte exactement ce que vous avez configuré : la clé API plus vos champs par utilisateur.
Les connexions existantes sont listées sur la page du serveur, où l'utilisateur peut aussi les supprimer :
Notes OAuth 2.0
- Les utilisateurs sont redirigés vers l'écran de consentement du fournisseur puis reviennent exactement à la page de départ.
- Si un refresh token meurt, la connexion stockée est supprimée et le chat demande à l'utilisateur de se reconnecter.
- Supprimer une connexion dans QAnswer ne révoque pas l'autorisation côté fournisseur — faites-le dans les réglages de sécurité du fournisseur.