Jetons d'accès personnels, authentification machine à machine, et définition des clés API et leurs scénarios réels

Si vous développez un logiciel ou un produit SaaS, vous rencontrerez souvent un cas d'utilisation large ou une demande de fonctionnalité : requêtes API. Les clients d'entreprise plus importants peuvent vouloir un accès programmatique aux ressources, soit au niveau personnel ou organisationnel.

Dans ces cas, les clés API, les jetons d'accès personnels (PATs), et l'authentification machine à machine (M2M) sont souvent nécessaires. Dans cet article, nous explorerons les différences entre ces méthodes et comment elles peuvent être utilisées dans le développement de produits B2B pour les développeurs.

Les similarités#

Prenons d'abord un moment pour examiner les similarités entre ces trois méthodes.

1. Objectif de sécurité : Les trois méthodes sont utilisées pour sécuriser et contrôler l'accès aux APIs, services, ou ressources. Elles servent toutes à l'authentification et/ou à l'autorisation.
2. Approche par jeton : Chaque méthode implique généralement l'utilisation d'une chaîne unique ou d'un jeton pour l'identification. Ces jetons sont généralement envoyés avec les requêtes API, souvent dans les en-têtes ou comme paramètres de requête.
3. Révocables : Les jetons ou clés dans les trois méthodes peuvent être révoqués ou invalidés s'ils sont compromis ou ne sont plus nécessaires. Cela permet de répondre rapidement aux menaces de sécurité sans changer le système sous-jacent.
4. Accès programmable : Les trois méthodes facilitent l'accès programmatique aux APIs ou services. Elles permettent l'automatisation et l'intégration entre différents systèmes ou applications.
5. Auditable : L'utilisation de ces méthodes d'authentification peut être enregistrée et auditée. Cela permet de suivre l'accès aux APIs, surveiller des activités suspectes, et établir des rapports de conformité.
6. Adaptable au contrôle d'accès : Les trois méthodes peuvent être mises en œuvre avec différents niveaux de contrôle d'accès et de permissions. Elles peuvent être adaptées à divers modèles de sécurité et exigences architecturales.
7. Indépendant du protocole : Bien que souvent utilisées avec les APIs REST, ces méthodes peuvent être appliquées à divers types d'APIs et protocoles.

Comprendre ces similarités aide à reconnaître les bases communes de ces méthodes d'authentification. Leurs différences permettent de choisir la solution la plus appropriée pour des cas d'utilisation spécifiques et des exigences de sécurité.

Passons maintenant à leurs différences, en nous concentrant sur leurs cas d'utilisation et quand utiliser chaque méthode.

Les différences#

Clés API#

Les clés API sont utilisées pour identifier et autoriser l'application ou le service appelant. Elles sont généralement de longue durée et statiques jusqu'à ce qu'elles soient renouvelées et ont souvent un ensemble de permissions fixes. Elles sont principalement utilisées pour les communications entre serveurs ou pour accéder à des données publiques, ces jetons ne représentent généralement pas un utilisateur spécifique.

Comment fonctionnent les clés API ?#

Une clé API est émise par un fournisseur d'API et donnée à un consommateur d'API enregistré [1], qui l'inclut dans chaque requête. Le serveur API vérifie ensuite la clé API pour valider l'identité du consommateur avant de retourner les données demandées.

Les clés API ne sont pas aussi efficaces que d'autres formes d'authentification API, telles que OAuth et JWT, mais elles jouent tout de même un rôle important en aidant les producteurs d'API à surveiller l'utilisation tout en gardant les données sensibles sécurisées.

[1] : Un consommateur d'API est toute application, service, ou utilisateur qui interagit avec une API pour accéder à ses fonctionnalités ou données. Ils envoient des requêtes à l'API pour effectuer des opérations telles que récupérer, créer, mettre à jour, ou supprimer des ressources. Les consommateurs d'API peuvent être des applications web, des applications mobiles, d'autres serveurs, ou même des développeurs individuels qui utilisent l'API pour s'intégrer à d'autres services ou pour construire de nouvelles fonctionnalités sur des plateformes existantes.

Postman : Qu'est-ce qu'une clé API ?

Cas d'utilisation#

Lorsque les gens discutent des cas d'utilisation des clés API, ils mentionnent souvent l'automatisation, le partage de données, les tests, le développement, et le contrôle de la sécurité. Cependant, ces cas sont plutôt techniques. Dans des scénarios réels, l'objectif le plus courant lors de la création de produits est l'intégration.

Exemple 1 : Intégration avec Zapier#

Zapier : Ajout d'authentification avec la clé API

Zapier est un outil d'automatisation populaire qui connecte différentes applications web. Lors de l'intégration d'une application avec Zapier, des clés API sont utilisées pour authentifier et autoriser l'accès à l'API de l'application. Par exemple, si vous souhaitez automatiser des tâches entre un système CRM et un outil de marketing par email, vous génèreriez une clé API à partir du système CRM et la fourniriez à Zapier. Cette clé est ensuite utilisée pour authentifier les requêtes de Zapier vers l'API du CRM, permettant aux données de circuler en toute sécurité entre les deux systèmes.

Exemple 2 : Intégration avec Stripe#

Stripe utilise des clés API pour une intégration sécurisée avec diverses plateformes et applications. Utilisez le tableau de bord des développeurs pour créer, révéler, supprimer, et faire rouler les clés API.

Jetons d'accès personnels (PATs)#

Un jeton d'accès personnel est un autre concept similaire mais représente l'identité et les permissions d'un utilisateur spécifique, est généré dynamiquement après une authentification réussie ou une connexion, et a généralement une durée de vie limitée mais peut être rafraîchi. Ils offrent un contrôle d'accès granulaire aux données et capacités spécifiques à l'utilisateur et sont couramment utilisés pour des outils de ligne de commande, scripts, ou accès personnel aux APIs.

Comment fonctionnent les PATs#

1. Création et gestion : Les utilisateurs génèrent des PATs via les paramètres de leur compte sur la plateforme respective.
   • Par exemple, dans GitHub, les utilisateurs peuvent créer des PATs précis ou classiques avec des permissions spécifiques et des dates d'expiration.
   • Dans les produits Atlassian comme Jira et Confluence, les utilisateurs peuvent créer des PATs depuis les paramètres de leur profil, en spécifiant le nom du jeton et une expiration optionnelle.
2. Utilisation : Les PATs sont utilisés comme jetons porteurs dans l'en-tête Authorization des requêtes API. Cela signifie qu'ils sont inclus dans les en-têtes HTTP pour authentifier la requête.
   • Ils permettent un accès sécurisé aux ressources API, permettant aux utilisateurs d'exécuter des actions telles que créer, lire, mettre à jour et supprimer des ressources en fonction des permissions accordées au jeton.
   • Les PATs peuvent être utilisés dans plusieurs applications au sein d'une plateforme, offrant une manière unifiée de gérer l'accès et les permissions.
3. Révocation et configuration d'expiration :
   • Les PATs offrent une sécurité renforcée en permettant aux utilisateurs de révoquer des jetons s'ils sont compromis, sans avoir à changer le mot de passe du compte.
   • Les plateformes recommandent souvent de définir des dates d'expiration pour les PATs afin de réduire le risque d'exploitation des jetons de longue durée.

Cas d'utilisation#

Il y a deux scénarios typiques,

Automatisation et script

Cela signifie qu'un développeur utilise un PAT pour automatiser le déploiement de code d'un référentiel à un environnement de production, réduisant l'intervention manuelle et assurant la cohérence.

Par exemple, les utilisateurs GitHub peuvent créer des PATs pour authentifier les opérations Git via HTTPS et interagir avec l'API REST de GitHub. Ceci est utile pour les développeurs qui ont besoin d'automatiser des tâches telles que le clonage de référentiels, le push des commits, ou la gestion des issues et des pull requests.

Intégration avec des applications externes

Cela signifie permettre une communication sécurisée entre différents systèmes et applications. Cela ressemble au scénario où une intégration de clé API mais le PAT représente l'utilisateur, non le client ou l'application.

Par exemple, un chef de projet utilise un PAT pour intégrer un outil de gestion de projet avec un système de suivi des bugs externe, permettant un échange de données sans faille et une synchronisation, comme Atlassian (Jira et Confluence).

Les scénarios ci-dessus ressemblent davantage à des outils pour développeurs. Les PATs sont-ils uniquement utiles pour ce genre de produits ? Non. Voici deux exemples supplémentaires : l'un concerne un système CMS, et l'autre un outil de productivité.

Exemple 1 : Contentful#

Contentful : Jetons d'accès personnels

Contentful est une plateforme CMS sans tête qui offre des PATs comme alternative aux jetons OAuth pour accéder à leur API de gestion de contenu (CMA).

Les fonctionnalités clés incluent :

• Les utilisateurs peuvent créer plusieurs jetons avec des portées et permissions différentes.
• Les jetons sont liés au compte de l'utilisateur, héritant de ses permissions.
• Les PATs sont particulièrement utiles pour les besoins de développement et d'automatisation.

Exemple 2 : Airtable#

Création de Jetons d'Accès Personnels | Support Airtable

Airtable - une plateforme de collaboration dans le cloud, met en œuvre des PATs pour l'accès aux APIs.

Leur système permet :

• La création de plusieurs jetons avec des portées et niveaux d'accès variés.
• Les jetons peuvent être limités à des bases ou espaces de travail spécifiques.
• Les administrateurs d'entreprise peuvent créer des jetons avec un accès plus large à travers toute l'organisation.

Authentification machine à machine (M2M)#

M2M est conçu pour la communication service à service sans intervention humaine. Cela provient de l'idée que les noms d'utilisateur et mots de passe sont insuffisants pour protéger les services et ne sont pas efficaces pour une automatisation adéquate.

Les applications machine à machine (M2M) adoptent maintenant le Flux de Credentials Client, défini dans le protocole d'autorisation OAuth 2.0 RFC 6749. Cela peut également prendre en charge d'autres protocoles standard similaires. Oui, l'authentification M2M est plus stricte lorsqu'il s'agit de normes ouvertes par rapport aux PATs et aux clés API.

Elle authentifie l'application ou le service lui-même, pas un utilisateur, et elle implémente souvent des JWT (JSON Web Tokens) pour une authentification sans état. Cela fournit un moyen sécurisé pour les services d'interagir les uns avec les autres dans des systèmes distribués.

Comment fonctionne l'authentification machine à machine#

Elle suit un processus similaire :

1. Credentials Client : Chaque machine (ou service) possède un ID client et un secret uniques.
2. Requête de jeton : Le service envoie ces credentials au serveur d'autorisation.
3. Jeton d'accès : Après validation, le serveur d'autorisation émet un jeton d'accès, souvent un JWT (JSON Web Token).
4. Requêtes API : Le service utilise ce jeton pour authentifier et autoriser des requêtes API vers un autre service.
5. Validation : Le service récepteur valide le jeton avant de donner accès à ses ressources.

Cas d'utilisation#

Voici un exemple concis de l'utilisation de l'authentification machine à machine (M2M) pour la communication backend à backend :

Scénario : Le service A doit accéder aux données de l'API du service B.

1. Configuration :

   • Le service A est enregistré en tant que client auprès d'un serveur d'autorisation.
   • Le service A reçoit un ID client et un secret client.

2. Authentification :

   • Le service A demande un jeton d'accès au serveur d'autorisation :

3. Émission de jeton :

   • Le serveur d'autorisation vérifie les credentials et émet un jeton d'accès JWT.

4. Requête API :

   • Le service A utilise le jeton pour demander des données au service B :

5. Validation :

   • Le service B valide le jeton avec le serveur d'autorisation.

6. Réponse :

   • Si valide, le service B retourne les données demandées au service A.

Ce processus permet une communication sécurisée et automatisée entre le service A et le service B sans intervention d'utilisateur, en utilisant le flux de credentials client OAuth 2.0.

Communication device à device

La communication device à device, en particulier dans le contexte de l'IoT (Internet des Objets), repose principalement sur l'authentification machine à machine (M2M) pour assurer un échange de données sécurisé et efficace.

Par exemple, comme les appareils intelligents dans une maison, un thermostat intelligent communique avec un hub central d'automatisation domestique pour ajuster les réglages de température en fonction des préférences de l'utilisateur. Le thermostat utilise l'authentification M2M pour envoyer des données en toute sécurité au hub et recevoir des commandes, garantissant que seuls les appareils autorisés peuvent interagir avec le système de chauffage de la maison.

Résumé clé#

Ok, vous êtes arrivé à la fin de cet article. Puis-je avoir un résumé rapide ? Bien sûr ! Voici les points clés :

1. Portée : Les clés API sont larges, les PATs (Jetons d'Accès Personnels) sont spécifiques à l'utilisateur, et les jetons M2M (Machine à Machine) sont spécifiques au service.
2. Durée de vie : Les clés API sont de longue durée, les PATs ont une durée de vie plus courte, et les jetons M2M peuvent varier.
3. Représentation : Les clés API sont des chaînes opaques, les PATs peuvent être opaques ou structurés, et les jetons M2M utilisent souvent des JWTs.
4. Cas d'utilisation : Les clés API sont pour un accès API simple, les PATs sont pour des opérations centrées sur l'utilisateur, et les jetons M2M sont pour la communication service à service.