latchkey

Qu'est-ce que Latchkey ?

Latchkey est un outil en ligne de commande qui injecte des identifiants dans les commandes curl pour les API HTTP. Au lieu d'ajouter manuellement des en-têtes d'autorisation ou d'autres paramètres d'authentification à chaque requête, vous stockez les identifiants pour les services pris en charge et Latchkey ajoute automatiquement les arguments curl appropriés.

Il est principalement conçu pour les agents IA qui doivent effectuer des appels API en utilisant la syntaxe standard curl. Les agents peuvent utiliser des identifiants utilisateur déjà stockés ou déclencher une connexion interactive via navigateur pour collecter les identifiants de l'utilisateur.

Fonctionnalités principales

• Injection d'identifiants pour les requêtes curl : latchkey curl <arguments> transmet vos arguments de requête à curl tout en insérant automatiquement les identifiants stockés (par exemple, éliminant le besoin d'inclure un en-tête Authorization vous-même).
• Support intégré pour les API publiques connues via services list : liste les services tiers pris en charge nativement (exemples de services : Slack, Google Workspace, Linear et GitHub).
• Stockage manuel d'identifiants avec auth set : stockez les identifiants sous forme d'arguments curl arbitraires pour un service nommé, par ex. ajout d'un en-tête Authorization: Bearer ... une seule fois pour réutilisation dans les futures requêtes.
• Capture d'identifiants via navigateur avec auth browser : ouvre une fenêtre pop-up de connexion, extrait les identifiants API de la session navigateur, les stocke pour réutilisation, et peut inviter les utilisateurs à fournir des identifiants (non supporté par tous les services).
• Flux de travail adapté aux agents sans services intermédiaires : le projet positionne Latchkey comme une injection directe d'identifiants plutôt qu'un intermédiaire de type OAuth ou une couche d'intégration MCP ; en cas d'authentification navigateur, les requêtes sont effectuées directement au nom de l'utilisateur.

Comment utiliser Latchkey

1. Installer Latchkey : npm install -g latchkey (selon les instructions d'installation du dépôt).
2. Configurer les identifiants pour un service :
   • Flux navigateur (nécessite un environnement graphique) : latchkey auth browser slack.
   • Flux manuel : latchkey auth set slack -H "Authorization: Bearer xoxb-your-token".
3. Effectuer des appels API avec la syntaxe curl standard :
   • Exemple : latchkey curl -X POST 'https://slack.com/api/conversations.create' -H 'Content-Type: application/json' -d '{"name":"something-urgent"}'.

Cas d'usage

• Agent IA appelant des API avec des identifiants utilisateur : un agent peut exécuter latchkey curl ... pour les services pris en charge afin que les détails d'authentification soient gérés par Latchkey plutôt qu'intégrés dans le prompt ou le code de l'agent.
• Invitation interactive à fournir des identifiants pour un utilisateur : avec latchkey auth browser <service>, l'agent peut déclencher un flux de connexion navigateur qui collecte les identifiants de la session utilisateur et les stocke pour les appels ultérieurs.
• Tests API locaux répétables : configurez les identifiants une fois avec auth set et réutilisez-les pour plusieurs requêtes curl sans recopier les en-têtes d'autorisation.
• Extension du support pour un nouveau service en temps d'exécution (cas simples) : utilisez l'approche documentée mentionnée dans l'aperçu (« services register ») pour ajouter un support basique à un nouveau service si le support natif complet n'est pas disponible.
• Intégration dans un flux de compétences d'agent : le dépôt mentionne l'utilisation de Latchkey comme une « compétence » pour les frameworks d'agents (exemples de commandes incluent l'utilisation d'outils skills et l'installation depuis ClawHub).

FAQ

• Latchkey modifie-t-il la façon dont j'écris mes requêtes HTTP ? Non. Vous écrivez toujours des commandes curl classiques ; Latchkey injecte automatiquement les identifiants stockés lors de l'exécution de latchkey curl <arguments>.

• Comment les identifiants sont-ils stockés et réutilisés ? Les identifiants sont stockés par service via latchkey auth set (manuel) ou latchkey auth browser (capture navigateur). Les appels futurs latchkey curl réutilisent les identifiants stockés.

• L'option d'authentification navigateur est-elle toujours disponible ? Non. La documentation indique que seuls certains services supportent la fonctionnalité auth browser.

• Quels sont les risques de donner accès aux identifiants aux agents ? Le projet avertit que permettre aux agents IA d'accéder aux identifiants API peut être dangereux, surtout avec auth browser, car les agents peuvent effectuer la plupart des actions possibles pour l'utilisateur.

• Quels prérequis pour l'installation et l'authentification navigateur ? Le dépôt indique que curl, Node.js et npm doivent être présents en versions récentes. Pour auth browser, un environnement graphique est requis ; il existe aussi une commande ensure-browser qui détecte Chrome/Chromium/Edge ou télécharge Chromium via Playwright si aucun n'est trouvé.

Alternatives

• Authentification API directe avec OAuth ou jetons par requête : vous pouvez implémenter manuellement les flux OAuth ou injecter des jetons dans chaque requête. Cela diffère de Latchkey en exigeant une implémentation d'authentification ou une gestion répétée des identifiants plutôt qu'une injection centralisée des identifiants dans curl.
• Couches d'intégration de style MCP / serveurs d'outils pour agents : celles-ci introduisent un intermédiaire entre l'agent et le service cible. Le projet Latchkey se positionne comme n'introduisant pas d'intermédiaire dans le flux de travail typique.
• Gestionnaires génériques de credentials ou magasins de secrets utilisés directement par les scripts : vous pouvez stocker les jetons dans un gestionnaire de secrets et les récupérer via des scripts. Cela signifie généralement que la logique d'injection des en-têtes d'authentification reste votre responsabilité plutôt qu'une commande latchkey curl.
• Autres outils de wrappers API basés sur CLI : les alternatives peuvent fournir des commandes spécifiques à certains services, mais elles n'utilisent pas forcément le même flux pass-through curl ou ne supportent pas de larges patterns de requêtes de style curl.