L’OAuth d’OpenClaw

L’authentification par abonnement paraît simple jusqu’à ce que deux outils possèdent le même compte. Les connexions commencent alors à s’annuler, apparemment au hasard. La conception d’OpenClaw répond directement : un seul endroit par agent détient l’identifiant, la réutilisation d’outils externes est étroite et propre au fournisseur, et le rafraîchissement réécrit chez le propriétaire du jeton plutôt que dans une copie.

Le puits de jetons

• Les fournisseurs émettent souvent un nouveau jeton de rafraîchissement à chaque connexion ou renouvellement, et certains invalident le précédent pour le même utilisateur et la même application ; le symptôme pratique est de se connecter par deux outils et d’en voir un déconnecté plus tard sans raison apparente.
• Le magasin de profils est donc traité comme un puits : le runtime lit les identifiants à un seul endroit par agent, plusieurs profils coexistent et routent de façon déterministe, et dès qu’OpenClaw possède un profil local pour un fournisseur son jeton de rafraîchissement fait foi, un rejet étant signalé pour réauthentification au lieu de retomber sur la matière de jeton externe.
• Les identifiants utilisent une base partagée en lecture traversante avec des surcharges par agent : une base d’état partagée, une base d’agent pour les identifiants et le routage, une table pour les lignes d’identifiants et une autre pour l’ordre, le dernier bon, le refroidissement et l’usage ; les comptes personnels ajoutés par une personne connectée vivent plutôt dans des enregistrements liés à son identité.
• Les fichiers d’identifiants retirés sont traités explicitement : quand la base contient déjà des profils, un fichier résiduel n’est que des octets et sera archivé à la prochaine réparation, et quand le magasin est vide le runtime ne lit que les métadonnées nécessaires pour limiter une erreur de migration aux fournisseurs concernés, en refusant pour eux tout repli sur l’authentification par environnement pendant que les autres continuent.

Les jetons de rafraîchissement OAuth sont particulièrement sensibles : les copies ordinaires les ignorent par défaut parce que certains fournisseurs les font tourner ou les invalident après usage.

L’échange et le rafraîchissement

La connexion par abonnement est un échange de code d’autorisation avec clé de preuve : OpenClaw génère un vérificateur, un défi et un état aléatoire, ouvre l’URL d’autorisation du fournisseur avec les portées d’identité et hors ligne habituelles, et tente de capter le rappel sur un port en boucle locale dont l’hôte n’accepte que des adresses locales. En mode sans écran, ou quand le rappel ne peut pas s’attacher, vous collez la redirection à la place, et c’est le premier arrivé qui gagne. Le code est échangé contre des jetons, et l’identifiant de compte est extrait du jeton d’accès puis stocké avec l’accès, le rafraîchissement et l’expiration. À l’exécution, un jeton d’accès non expiré est utilisé tel quel, un jeton expiré est rafraîchi et réécrit chez son propriétaire plutôt que copié dans une base d’agent, et les identifiants gérés en externe sont relus au lieu de dépenser un jeton de rafraîchissement copié. Le flux est automatique, les jetons n’ont donc normalement pas besoin d’être gérés à la main.

Gérer plusieurs comptes

• Le schéma préféré est des agents séparés, parce qu’un agent est ses propres sessions, identifiants et espace de travail, le personnel et le professionnel n’interagissant donc jamais ; ajoutez les agents et configurez l’authentification par agent.
• Le schéma avancé garde plusieurs identifiants de profil pour un fournisseur dans un seul agent et choisit entre eux globalement par l’ordre d’authentification configuré ou par session avec une commande de modèle portant le suffixe de profil.
• Le schéma multi-utilisateur est le compte par personne sur une passerelle partagée : chaque personne vérifiée enregistre des comptes par fournisseur et en choisit un par défaut pour ses nouvelles discussions, les deux surfaces de connexion montrent la passerelle, la personne et la portée personnelle avant de demander des identifiants, et les identifiants personnels restent hors de la liste de profils partagés parce qu’un jeton de passerelle partagé n’identifie personne.

L’authentification des modèles OpenClaw est le tableau plus large de l’authentification des fournisseurs et La gestion des secrets d’OpenClaw l’alternative par référence aux clés collées.

Pourquoi des agents plutôt que des profils

Plusieurs profils dans un agent règlent le routage, pas l’isolation. L’agent partage toujours un espace de travail, un magasin de sessions et un jeu d’outils, une erreur de routage devient donc une erreur avec le compte de quelqu’un d’autre attaché. Des agents séparés rendent la frontière structurelle, et la documentation recommande cette voie en premier pour cette raison. La même logique gouverne la copie : quand un agent n’a pas de profil local, il lit le magasin partagé au lieu de cloner les identifiants dans sa base, et les jetons de rafraîchissement sont ignorés par les copies ordinaires parce que la rotation casserait la copie perdante. Si un agent a vraiment besoin d’un compte indépendant, la réponse est une connexion séparée pour cet agent plutôt qu’un jeton dupliqué. Le basculement de modèles d’OpenClaw explique la rotation et le refroidissement entre identifiants et Les modèles OpenClaw expliqués comment un modèle choisi en atteint un.

Sur Diali

Sur Diali les identifiants de modèles appartiennent à la plateforme, les clients ne lancent donc pas de connexions de fournisseur sur un serveur à eux, et la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque version. OpenClaw hébergé sur Diali décrit l’assistant hébergé et La sécurité Diali la frontière autour de chaque runtime.

• Un propriétaire par agent ; les copies perdent la course au rafraîchissement.
• Le rappel est en boucle locale ; coller la redirection est le repli.
• Des agents séparés isolent les comptes ; les profils ne font que router.