Explication des méthodes d'authentification courantes des API REST

Pour mettre en œuvre l'automatisation et l'orchestration, il est essentiel de comprendre le fonctionnement de l'authentification avec les API. La plupart des produits de votre environnement disposent probablement d'un mécanisme d'authentification. Il est donc important de connaître les nuances et les différences entre les diverses méthodes d'authentification afin d'automatiser les communications avec ces API. Dans cet article, je vous propose d'y voir plus clair en détaillant trois méthodes d'authentification API différentes.

Authentification par nom d'utilisateur et mot de passe

L'une des méthodes d'authentification les plus courantes pour les API REST est l'authentification par nom d'utilisateur et mot de passe. Plusieurs variantes utilisent ces identifiants, mais la plus répandue est l'authentification HTTP de base. Simple à appréhender pour les utilisateurs expérimentés d'API, elle peut s'avérer complexe pour les débutants.

Par RFC2617, Pour effectuer une requête HTTP avec l'authentification de base, il faut une chaîne encodée en base64 composée d'un nom d'utilisateur et d'un mot de passe, séparés par deux points. Cette chaîne est ensuite précédée de « Basic » suivi d'un espace. Pour illustrer cela, prenons l'exemple suivant :

Nom d'utilisateur : prénom.nom

Mot de passe : my5uper5ecretP@ssw0rd

Imaginez que vous ayez un nom d'utilisateur et un mot de passe comme dans l'exemple ci-dessus. Pour les utiliser dans une requête HTTP à une API, vous devez d'abord les combiner avec un deux-points :

prénom.nom:mon5uper5secretP@ssw0rd

Une fois cette étape réalisée, il faut les encoder en base64. En Python, vous pouvez procéder comme suit :

importer base64

auth_string = base64.b64encode(b':'.join(('first.last'.encode('latin1'), 'my5uper5ecretP@ssw0rd'.encode('latin1')))).strip()

Si vous imprimiez notre variable auth_string, vous obtiendriez la valeur suivante :

b'Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ='’

Maintenant que vous disposez de cette chaîne encodée, vous devez ajouter au début de cette variable la chaîne de méthode d'authentification (qui est « Basic »). La chaîne complète de la variable devrait être la suivante :

Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ=

Une fois cette chaîne de caractères créée, elle est ajoutée à un en-tête HTTP spécifique de votre requête HTTP. Cet en-tête est particulier et sert à l'authentification. Vous l'aurez deviné, il s'agit de l'en-tête « Authorization ». Pratique, non ?

Voici un exemple de commande cURL utilisant l'authentification de base :

AUTH=$(echo -ne "$BASIC_AUTH_USER:$BASIC_AUTH_PASSWORD" | base64 --wrap 0) curl \ --header "Content-Type: application/json" \ --header "Authorization: Basic $AUTH" \ --request POST \ --data '{"key1":"value1", "key2":"value2"}' \ https://example.com/

Authentification JWT

L'authentification JWT (JSON Web Token) est une forme courante d'authentification par jeton basée sur RFC 7519. L'authentification JWT se compose de trois parties principales : un en-tête, une charge utile et une signature. Chacune de ces parties est encodée en base64 et envoyée avec une requête HTTP d'authentification.

Un ensemble de revendications JWT est composé d'une ou plusieurs revendications spécifiées dans un objet JSON. Chaque revendication de cet ensemble possède une clé unique et une valeur correspondante. Par exemple, la structure typique d'un ensemble de revendications JWT est la suivante :

{ “iss”: “josh”, “exp”: 1617221146, “https://api.mycompany.com/some....”: true }

Chaque paire clé-valeur doit être unique et constitue une revendication individuelle au sein de l'ensemble de revendications. Le caractère arbitraire de ces clés n'est pas exigé par la norme RFC. Par conséquent, la structure de l'ensemble de revendications dans l'authentification JWT dépend de l'API ou du service utilisé.

Tout comme les valeurs d'en-tête et de signature, une fois votre revendication JWT (charge utile) définie, elle est encodée en base64. Vous pouvez tester ces valeurs sur https://jwt.io aussi.

Authentification OAuth2

L'authentification OAuth2 gagne en popularité car elle prend en charge de nombreux flux d'authentification auprès d'un même point de terminaison. Les développeurs peuvent ainsi créer des services robustes qui permettent l'autorisation dans diverses situations (application web, application de bureau, appareil mobile, etc.) en modifiant simplement quelques paramètres, au lieu de devoir implémenter un mécanisme d'authentification différent pour chaque cas.

Pour faciliter la compréhension des concepts d'authentification OAuth2, j'ai créé ce diagramme qui présente les quatre composants principaux :

1. Un utilisateur ou un système qui a besoin d'accès

2. Un serveur chargé de l'autorisation

3. Une application à laquelle l'accès est accordé via le serveur d'autorisation

4. Cette application accède ensuite aux données en fonction de cette autorisation.

Si vous souhaitez en savoir plus sur OAuth2, veuillez consulter la série en trois parties que j'ai écrite expliquant OAuth2 plus en détail ici :

• Partie 1 : Points de terminaison et types d’applications

• Partie 2 : Enregistrement d'une demande

• Partie 3 : Utilisation de l’API Microsoft Graph

En matière d'authentification, OAuth2 et JWT sont plus sécurisés que Basic et vous rencontrerez probablement les deux lors de l'utilisation d'API, notamment avec des produits comme EDR, SIEM, etc.

Il existe de nombreux autres types d'authentification pour les API REST, ainsi que des variantes des méthodes énumérées ci-dessus, mais j'espère que cela vous a aidé à comprendre les trois méthodes d'authentification les plus courantes utilisées par les API.