Les Jetons d’accès personnels (PAT), pour un meilleur contrôle des accès à l’API de Gandi

Pour faire des opérations sur les produits que l’on détient chez Gandi, on peut passer par l’interface utilisateur et se laisser guider par les différents menus, mais on peut aussi choisir de passer par l’API (application programming interface ou « interface de programmation d’application ») pour automatiser ces tâches ou pour faire des actions en masse, par exemple le renouvellement d’un grand nombre de domaines. Dans un cas comme dans l’autre, il faut s’identifier pour mener ces opérations et l’API nécessitait donc jusqu’ici que l’utilisateur soit détenteur d’une clé API, une chaine de caractères unique et personnelle générée sur le compte de l’utilisateur. Nous verrons que ce protocole a quelques imperfections qui l’amène à être désormais déprécié au profit d’un nouveau système de Jeton d’accès personnel (« Personal Access Token », ou « PAT »).

Des clés API dépréciées

Jusqu’ici, l’usage de l’API de Gandi nécessitait donc une identification par une clé. Cette clé pouvait être obtenue par l’utilisateur sur son compte (rubriques Organisations) et pouvait être utilisée sans limite de temps et pour l’ensemble des opérations possibles sur Gandi. L’avantage évident de ce mode d’identification est sa redoutable simplicité. Une fois entrée dans le programme chargé de communiquer avec l’API, la clé fonctionne comme un mot de passe automatiquement mémorisé par un navigateur et permet à l’utilisateur de ne plus s’en soucier. Mais cette simplicité a un coût : elle ne permet pas une gestion très fine des autorisations et peut poser des problèmes de sécurité.

• Des limites liées au contrôle des accès : chaque clé est liée à un utilisateur, même au sein d’une organisation. Et seul cet utilisateur peut révoquer cette clé. Dans l’hypothèse où une entreprise doit utiliser ces clés, elle devra à chaque mouvement de personnel faire le nécessaire créer de nouvelles clés et s’assurer que les anciennes ont bien été révoquées. Par ailleurs, la clé donne accès à l’ensemble des services accessibles par l’utilisateur, il n’est pas possible de la limiter à certaines permissions ou ressources.
• Des limites en termes de sécurité : la clé API donnant à son utilisateur un accès complet aux différents services proposés par Gandi, une interception de ce sésame serait comparable au partage des identifiants du compte et la possibilité pour un tiers de modifier ou supprimer des domaines, des hébergements, des certificats SSL, etc.

Une gestion plus fine avec les PAT

Pour faire face à ces potentielles difficultés de contrôle des accès, un autre modèle d’identification est désormais proposé. Il s’agit des Personal Access Tokens (PAT) ou Jetons d’accès personnels, qui répondent à des caractéristiques différentes :

• Ces jetons sont liés à une seule organisation, et non plus à un utilisateurs susceptibles de s’en servir pour plusieurs organisations
• Ces jetons ont une date d’expiration et n’exigent donc plus une révocation de la part de l’utilisateur.
• Ces jetons sont générés par l’utilisateur et non par Gandi : il est possible de nommer chaque jeton en fonction de son usage et de limiter les permissions liées à chaque jeton pour ne pas ouvrir, comme la clé API, un accès à toutes les opérations que permet l’API de Gandi.
• Il est possible pour l’organisation de révoquer un jeton sans attendre de l’utilisateur qu’il le fasse.

Les jetons permettent donc d’obtenir un plus grand contrôle des accès des différents utilisateurs et des actions qui leur sont autorisées. Les PAT sont donc « scopés », c’est à dire qu’ils ont un périmètre d’action (scope en anglais) : ils sont limités à une organisation, ou un ensemble de ressources pré-paramétrées, et déterminent une limite sur les actions possibles sur ces ressources.
Ainsi, il est possible de faire un audit de sécurité avec l’accès aux listes des permissions donnés aux administrateurs de l’organisation et de savoir à quel(s) usage(s) sont destinés chacun de ces jetons. La création de ces PAT, nous le verrons, reste rapide et la gestion des autorisations se trouve grandement simplifiée notamment grâce à l’expiration programmée (ou la révocation par l’organisation) des jetons créés.

Les PAT, concrètement

C’est donc désormais en tant qu’organisation et non plus en tant qu’utilisateur que vous allez pouvoir configurer votre accès à l’API Gandi.

Choisissez sur votre compte la rubrique « Organisations » puis sélectionnez l’organisation concernée.

• Dans l’onglet « partages », un cadre dédié vous permet de créer un nouveau jeton.
• (notons qu’il est également possible d’accéder à ce menu depuis l’onglet « Vue Générale)

• Nommer ce jeton de manière explicite, pour identifier son usage et choisissez sa durée de vie avant expiration (de 7 jours à un an)

Configurer éventuellement les permissions associées à ce jeton, pour permettre à son utilisateur d’agir sur la facturation, les domaines, l’hébergement, les ressources cloud ou les certificats SSL.

Les Jetons d’Accès Personnels (PAT) sont donc bien plus qu’un substitut plus flexible aux traditionnelles clés API. Ce mode d’identification permet donc toujours de faire des actions de masse ou des tâches répétitives, mais également de permettre par exemple à un prestataire de faire certaines opérations sans avoir accès à l’intégralité du compte de l’organisation. Davantage de contrôle, plus de sécurité, les bonnes raisons de passer aux PAT ne manquent pas.

Tagged in API