Authentification machine à machine pour les services et les tâches planifiées
L'authentification machine à machine permet à un service, à une tâche planifiée ou à un script backend de prouver son identité à une API sans qu'aucun utilisateur soit présent. La méthode standard est le grant client credentials d'OAuth, où le service échange ses propres identifiants contre un jeton d'accès de courte durée. Skycloak Platform est conçu pour émettre ces jetons, avec private_key_jwt et DPoP prévus pour sa première version.
Comment fonctionne le grant client credentials
Avec le grant client credentials, chaque service est enregistré comme client OAuth avec son propre identifiant et ses propres secrets. Lorsqu'il doit appeler une API, il envoie ces identifiants au point de terminaison de jetons et reçoit un jeton d'accès, qu'il joint à chaque requête. L'API vérifie la signature, l'émetteur, l'audience et les scopes du jeton avant tout traitement, et elle n'a jamais besoin de voir les identifiants du service.
Comme aucun utilisateur ne se connecte, ce flux n'a ni navigateur, ni redirection, ni écran de consentement. Chaque service devrait avoir son propre client plutôt que d'en partager un, pour que vous sachiez quel service a fait un appel et puissiez en révoquer un sans toucher aux autres. Les scopes du jeton limitent ce que chaque service peut faire, par exemple lire les factures sans pouvoir les modifier.
Remplacer les secrets partagés par private_key_jwt et DPoP
L'identifiant client le plus simple est un secret partagé, une longue chaîne aléatoire que connaissent à la fois le service et le serveur d'autorisation. Cela fonctionne, mais le secret doit être copié dans la configuration, il peut fuiter par les journaux ou les dépôts de code, et quiconque le détient peut demander des jetons. Avec private_key_jwt, le service signe plutôt une courte assertion avec une clé privée qui ne le quitte jamais, et le serveur vérifie cette assertion avec la clé publique correspondante.
DPoP, pour demonstrating proof of possession (preuve de possession), va plus loin en liant le jeton d'accès à une clé détenue par le service. Chaque requête porte une nouvelle preuve signée avec cette clé, si bien qu'un jeton copié depuis un journal ou intercepté en route ne peut pas servir à quelqu'un d'autre. private_key_jwt et DPoP sont tous deux prévus pour la première version de la plateforme, avec les pushed authorization requests (PAR) pour les flux où un utilisateur est présent.
Jetons de courte durée, scopes et piste d'audit
Les jetons d'accès des services gagnent à être de courte durée, comptée en minutes plutôt qu'en jours, car une durée courte limite le temps pendant lequel un jeton divulgué reste utilisable. Un service peut simplement demander un nouveau jeton quand l'ancien expire, donc une durée courte lui coûte très peu. Avec des scopes étroits et un client distinct par service, l'effet d'une fuite reste limité et facile à retracer.
Sur Skycloak Platform, les clients de vos services se gèrent par une API de gestion publique unique, que la console, une CLI et un serveur MCP utilisent aussi. Les clés de cette API portent des scopes de lecture et d'écriture par ressource, chaque écriture est auditée et des limites de débit s'appliquent par clé et par espace de travail. Créer un client, modifier ses scopes ou renouveler ses identifiants laisse donc une trace de qui l'a fait et quand.
Questions fréquentes
Le grant client credentials est-il la même chose qu'une clé d'API ?
Non. Une clé d'API est en général une chaîne de longue durée envoyée avec chaque requête, alors que le grant client credentials échange les identifiants du service contre un jeton d'accès de courte durée doté de scopes. L'API ne voit alors que des jetons qui expirent, et les identifiants eux-mêmes ne sont envoyés qu'au point de terminaison de jetons.
Les clients machine à machine fonctionnent-ils avec les bibliothèques OAuth standard ?
Oui. Le grant client credentials fait partie d'OAuth standard, donc toute bibliothèque cliente OAuth qui le prend en charge peut demander des jetons à la plateforme. private_key_jwt et DPoP sont aussi des standards ouverts, et tous deux sont prévus pour la première version de la plateforme.
Découvrez Skycloak Platform par vous-même
Réservez une démo : nous vous présentons la plateforme en partant de vos propres parcours de connexion.