Documentation
Authentification
Choisis entre une clé d’API aux portées définies par son propriétaire et un jeton OAuth borné par le consentement de l’utilisateur.
Choisir son chemin
La règle tient en une question : le programme agit-il pour TOI, ou pour quelqu’un d’autre ? Pour toi — un script, un cron, un agent que tu héberges — prends une clé d’API. Pour un tiers dont tu ne veux pas détenir le compte, passe par OAuth.
Clé d’API — ton programme, en ton nom
Tes scripts, ton serveur, ta CI, ton agent à toi. Personne d’autre que toi n’est dans la boucle : tu crées la clé dans tes réglages, tu la poses dans un en-tête, il n’y a ni écran de consentement ni jeton à rafraîchir. C’est notre chemin machine-à-machine — la place que tient `client_credentials` ailleurs.
- Ce qu’on présente
- Authorization: Bearer kaneme_… — 5 clés actives au plus, affichée une seule fois.
- Ce que ça autorise
- Tu choisis ses portées à la création. Lire, mesurer, écrire et générer sont proposés ; publier un certificat et gérer le cycle de vie restent décochés par défaut.
- Comment on coupe
- Révocable à l’unité dans Connexions. La révocation prend effet à l’appel suivant : rien n’est mis en cache côté serveur.
La limite : Les droits d’une clé ne peuvent pas être élargis après sa création : révoque-la et crée-en une autre. Les anciennes clés ambiguës ont été ramenées à la lecture seule.
OAuth — un agent, au nom de quelqu’un
Un connecteur MCP (Claude, ChatGPT et les autres) ou l’extension Kaneme, qui agit pour un utilisateur de Kaneme, y compris quand cet utilisateur n’est pas toi. Le client s’enregistre tout seul, l’utilisateur voit ce qui est demandé et coche.
- Ce qu’on présente
- Code d’autorisation avec PKCE, puis un jeton court qui se rafraîchit, émis par Kaneme. Le 401 du serveur MCP annonce lui-même où lire les métadonnées (RFC 9728).
- Ce que ça autorise
- 6 portées, cochées une par une. Ce qui dépense est séparé de ce qui lit : générer dans ta voix et la lire ne partagent pas une case.
- Comment on coupe
- Chaque agent connecté est listé dans Connexions, avec ce qu’il a obtenu, et se révoque d’un clic. La révocation coupe le DROIT tout de suite ; le jeton déjà émis, lui, reste valide jusqu’à son expiration — il ne donne alors plus accès à rien.
La limite : Ce qui décide, c’est l’octroi enregistré à ton consentement, relu à chaque appel — pas ce que le jeton prétend. Un accès retiré dans Connexions coupe donc à l’appel suivant, même si le jeton n’a pas encore expiré. Un jeton OAuth n’ouvre que le serveur MCP, ou pour l’extension ses propres routes : l’API REST se parle avec une clé.
Les portées OAuth
Sur les 6, « émettre un certificat public » et « gérer le cycle de vie de tes contenus » arrivent décochées : l’utilisateur doit les vouloir.
voice:read— Lire tes voix et ton compte- Tes voix, leurs textes, tes convictions, tes documents et ton solde. Rien n’est modifié, aucun crédit consommé.
voice:measure— Mesurer un texte contre ta voix- Relevé gratuit, tampon et comparaison de deux écritures. Le tampon et la comparaison consomment des crédits.
voice:write— Créer et modifier tes voix et tes documents- Créer une voix, y ajouter des textes, créer et modifier des documents. Consomme des crédits.
voice:generate— Écrire dans ta voix- Écrire ou réaligner un texte à ta place, dans ta voix. Consomme des crédits.
voice:certify— Émettre un certificat public- Publier un certificat public que tout le monde peut vérifier. La préparation est gratuite, la publication consomme des crédits.
voice:manage— Gérer le cycle de vie de tes contenus- Portée séparée : archiver, mettre à la corbeille, restaurer ou révoquer. Gratuit, sans aucune suppression définitive.
Mesurer sans écrire est une portée à part entière : `voice:measure` se coche seule, sans `voice:generate` ni `voice:write`. Un prestataire mandaté peut donc vérifier sa livraison contre la voix de son client — sans jamais pouvoir écrire avec, ni la modifier. Le titulaire accorde l’accès, et le retire quand il veut.