L’authentification des modèles dans OpenClaw

Deux choses différentes s’appellent authentification dans un déploiement OpenClaw. L’une est la façon dont un client prouve son identité à la passerelle. L’autre, traitée ici, est la façon dont la passerelle prouve la sienne à un fournisseur de modèles. Pour une machine toujours allumée, la documentation est directe : une clé d’API est l’option la plus prévisible, les parcours par abonnement fonctionnant quand ils correspondent au modèle de compte du fournisseur.

Poser un identifiant sur l’hôte

• Créez une clé dans la console du fournisseur, exportez-la sur l’hôte de la passerelle et vérifiez le statut des modèles ; quand la passerelle tourne en service, placez la clé dans le fichier d’environnement du répertoire d’état pour que le démon la lise, redémarrez, puis revérifiez le statut et lancez le diagnostic.
• Réutiliser une connexion locale d’assistant tient en deux étapes et non une : connectez cet outil en ligne de commande au fournisseur sur l’hôte, puis dites à OpenClaw de router les modèles de ce fournisseur par son backend local ; le service de passerelle doit pouvoir résoudre cet exécutable dans son chemin de recherche, et un chemin non standard exige une enveloppe enregistrée par un plugin.
• Un jeton d’installation de longue durée est l’autre chemin pris en charge : générez-le sur une machine où l’assistant est installé, puis stockez-le sur l’hôte avec la commande de connexion, qui exige un terminal interactif ; la saisie manuelle de jeton fonctionne pour tout fournisseur et écrit dans le même magasin par agent.
• Les profils vivent dans le fichier de base de chaque agent, et les détails de point de terminaison comme l’adresse de base, le format de fil, les identifiants de modèles, les entêtes et les délais appartiennent à la configuration plutôt qu’à un profil d’authentification ; les anciennes installations avec des fichiers d’identifiants à plat sont importées par la commande de réparation, qui garde des sauvegardes horodatées à côté des originaux.

OpenClaw ne lit, ne stocke, ne rafraîchit ni ne transmet jamais les jetons de connexion natifs.

Vérifier, sonder, faire tourner

La commande de statut montre ce qui est configuré, et une variante adaptée à l’automatisation sort avec un code quand un identifiant est expiré ou manquant et un autre quand un identifiant expire bientôt, ce qui la rend utilisable dans une vérification planifiée. Une sonde en direct appelle réellement le fournisseur, et ses lignes peuvent venir des profils, des variables d’environnement ou du fichier de registre. Deux résultats de sonde méritent d’être reconnus : un profil omis de l’ordre d’authentification configuré est signalé comme exclu plutôt que sauté en silence, et un fournisseur avec une authentification valide mais sans modèle résolvable est signalé comme sans modèle plutôt que comme une authentification cassée. Les refroidissements de limite de débit portent sur un modèle, un profil en refroidissement pour un modèle pouvant donc encore servir un modèle voisin du même fournisseur. Pour la rotation des clés, l’ordre de priorité va d’un remplacement unique épinglé, à une variable de liste, à la variable de clé unique, puis à toute variable partageant le préfixe, la liste combinée étant dédoublonnée avant usage.

Choisir l’identifiant qui s’exécute

• La rotation est volontairement étroite : OpenClaw ne passe à la clé suivante que si le texte d’erreur correspond à une limite de débit, un quota épuisé, une ressource épuisée ou une phrase de trop de requêtes, les autres erreurs n’étant jamais réessayées avec une autre clé, et si toutes échouent la dernière erreur est renvoyée.
• À la connexion, un identifiant de profil garde plusieurs comptes d’un même fournisseur séparés dans un seul agent, et une option de forçage supprime les profils enregistrés de ce fournisseur dans le répertoire de l’agent choisi avant de relancer le parcours, ce qui répare un profil bloqué ou rattaché au mauvais compte ; cela ne révoque rien chez le fournisseur.
• Par session, une commande de modèle avec un suffixe de profil épingle un identifiant pour cette conversation, tandis que par agent les commandes d’ordre d’authentification lisent, définissent et effacent l’ordre stocké dans l’état de cet agent ; retirer l’authentification d’un fournisseur par le plan de contrôle interrompt aussi les exécutions actives sur ce fournisseur avec une raison d’arrêt explicite pour que les clients expliquent l’interruption.

L’OAuth d’OpenClaw expliqué couvre le versant abonnement du même magasin et La gestion des secrets d’OpenClaw la façon de référencer un identifiant plutôt que de le coller.

Ce qu’on oublie

Supprimer une authentification enregistrée dans OpenClaw n’est pas une révocation chez le fournisseur. Le profil stocké disparaît, les exécutions actives sur ce fournisseur s’arrêtent, et rien d’autre ne change côté fournisseur : une clé divulguée doit donc être tournée ou révoquée dans le tableau de bord du fournisseur. Le second piège facile est l’identifiant : les profils par clé d’API et par abonnement du même éditeur partagent un identifiant de fournisseur canonique, et un ancien identifiant scindé trouvé dans la configuration est une entrée de migration que la réparation réécrit plutôt qu’un second fournisseur à maintenir. Les modèles OpenClaw expliqués explique comment un modèle sélectionné se résout vers l’un de ces identifiants et Le doctor d’OpenClaw est la commande qui répare le magasin.

Sur Diali

Sur Diali les identifiants de modèles sont gérés par la plateforme et la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque version, il n’y a donc aucune clé à coller sur un serveur. OpenClaw hébergé sur Diali décrit l’assistant hébergé et La sécurité Diali la frontière autour de chaque runtime.

• Authentification de fournisseur, pas de passerelle : deux portes.
• La rotation ne part que sur un texte de limite de débit.
• Supprimer un profil localement ne révoque jamais la clé en amont.