Aller au contenu

Connecter une IA à votre API interne avec OAuth

Mis à jour le 30 octobre 2026 · Publié le 30 octobre 2026

Pour connecter une IA à une API interne avec OAuth, déclarez l'application OAuth de votre API dans l'onglet « API cible » d'un serveur Voozeo MCP : chaque personne se connecte alors avec son propre compte, et chaque appel atteint votre API avec les droits de cette personne, jamais avec un secret partagé.

Pourquoi pas un secret partagé

Par défaut, un serveur appelle votre API avec un secret stocké pour tout le monde. C'est simple, mais toutes les personnes qui utilisent l'IA agissent avec les mêmes droits, et un secret qui fuite expose tout ce qu'il atteint. Pour une API interne, on veut souvent l'inverse : chacun agit en son nom, et vous gardez les droits, la traçabilité et la révocation que votre API fournit déjà.

Voozeo MCP propose deux façons d'y arriver.

OAuth 2.0Transmis par l'appelant
Qui se connecteChaque personne, chez le fournisseur de votre API, au premier appelChaque personne, sur la page de consentement d'une passerelle OAuth que vous exploitez
Où vit l'identifiantLe jeton du fournisseur, stocké chiffré par VoozeoNulle part : Voozeo transmet un en-tête reçu et ne stocke rien
Clé MCPAucuneObligatoire, utilisée par la passerelle seule
Adapté quandLe fournisseur de votre API gère OAuth 2.0 avec le flux par code d'autorisationVous exploitez déjà une passerelle OAuth, ou votre API attend un jeton particulier

Option 1 : OAuth 2.0 avec Voozeo en courtier

Voozeo joue le rôle de serveur d'autorisation face à l'IA et chaîne la connexion vers le fournisseur de votre API. L'IA ne reçoit jamais le jeton du fournisseur.

  1. Chez le fournisseur de votre API, créez une application OAuth. Copiez-y l'« URL de rappel à déclarer chez votre fournisseur » affichée dans l'onglet, exactement telle quelle.
  2. Dans l'onglet « API cible », choisissez « OAuth 2.0 » et renseignez l'identifiant client, le secret client, l'URL d'autorisation et l'URL du jeton du fournisseur. Si votre fichier OpenAPI déclare un schéma OAuth 2.0, les URL sont préremplies à titre de suggestion ; vérifiez-les auprès de votre fournisseur.
  3. Choisissez les périmètres (scopes) à demander : demandez-en le moins possible pour vos outils. Voir OAuth 2.0.
  4. Ajoutez le serveur à votre IA avec son URL seule : il n'y a ni clé MCP ni en-tête. Voir serveurs utilisant OAuth.
  5. Au premier appel, une page de consentement Voozeo affiche l'adresse qui recevra l'accès, le fournisseur et les périmètres. La personne clique sur « Autoriser », se connecte chez votre fournisseur avec son propre compte et accepte.

Ensuite, chaque appel d'outil part avec le jeton de cette personne. Voozeo utilise toujours PKCE avec le fournisseur, et refuse les adresses privées et internes pour les URL du fournisseur. Un serveur qui utilise OAuth n'accepte qu'OAuth : une ancienne clé MCP cesse de fonctionner.

Option 2 : un identifiant transmis par une passerelle OAuth

Si vous exploitez déjà une passerelle OAuth devant vos outils, ou si votre API attend son propre jeton, choisissez plutôt « Transmis par l'appelant ». Voozeo ne stocke aucun secret : à chaque appel d'outil, il transmet à votre API l'en-tête reçu, avec le même nom et la même valeur.

  1. Dans l'onglet « API cible », choisissez « Transmis par l'appelant » et saisissez le nom de l'en-tête (authorization par défaut).
  2. Dans l'onglet « Connexion », copiez l'URL qui contient la clé et déclarez-la dans votre passerelle. Ne la donnez pas aux utilisateurs : elle porte la clé du serveur.
  3. L'IA se connecte à la passerelle. Sur sa page de consentement, la personne saisit son propre identifiant ; la passerelle l'ajoute en en-tête à chaque appel.

Voir identifiants par utilisateur avec une passerelle OAuth pour le détail et les limites, comme le quota partagé par tous les utilisateurs du serveur.

Protections communes aux deux options

  • Moindre privilège : ne demandez que les périmètres dont vos outils ont besoin, et n'exposez que les outils nécessaires à l'IA. Voir choisir et décrire les outils.
  • Révocation : sur un serveur OAuth 2.0, « Révoquer toutes les autorisations » déconnecte toutes les IA d'un coup. Changer le type d'authentification, l'identifiant client ou les URL du fournisseur fait de même. Une personne peut aussi retirer l'accès depuis son compte chez votre fournisseur. Voir autorisations actives.
  • Aucune transmission de jeton : le jeton de votre fournisseur n'est jamais remis à l'IA, et le jeton détenu par l'IA n'est jamais envoyé à votre fournisseur.
  • Quota et journal : chaque appel compte sur le quota de l'espace et apparaît dans le journal des appels, sans ses arguments ni ses résultats sauf si vous activez le mode diagnostic de ce serveur.

Vérifier avant de partager le serveur

  1. Testez avec votre propre compte : demandez à l'IA une action que votre compte peut faire, puis une qu'il ne peut pas faire. Votre API doit refuser la seconde.
  2. Ouvrez le journal des appels et vérifiez le statut des deux appels. Voir le journal des appels.
  3. Révoquez les autorisations et vérifiez que l'IA doit se reconnecter.

Pour aller plus loin

Commencer