Même si curl est mon outil préféré pour appeler des APIs, il faut avouer qu’il est parfois plus confortable d’utiliser une IHM telle que Postman. Ce dernier supporte de nombreux modes d’authentification dont l’OAuth2. Cependant, OAuth2 propose 4 types d’autorisation. Or, Postman n’en supporte que 2 actuellement : Authorization Code et Client Credentials.

Pour autant, cela ne veut pas dire qu’il n’est pas possible d’utiliser Postman pour interagir avec une API avec un type d’autorisation OAuth2 non supporté comme le Resource Owner Password Credentials Grant.

Sommaire

Configuration

Dans un premier temps, il est préférable de créer des variables globales afin de pouvoir réutiliser certains éléments de configuration tels que le client_id, le secret_id, l’identifiant utilisateur ou le mot de passe 1.

Ensuite, il est nécessaire de créer un environnement « MyEnvironment ». Cet environnement n’aura aucune variable. En revanche, il est nécessaire pour stocker le token d’accès et le token de renouvellement.

Récupération de l’access_token

Maintenant, nous pouvons déclarer l’appel qui permet de récupérer l’access_token. Pour cela, il faut généralement faire un POST sur l’endpoint de type « token ». Voici à quoi doit ressembler la configuration :

Vous avez pu vérifier que la requête permet de récupérer un access_token. Nous allons donc ajouter le test suivant qui va stocker l’access_token et le refresh_token dans l’environnement « MyEnvironment » :

var data = JSON.parse(responseBody);
postman.setEnvironmentVariable("accessToken", data.access_token);
postman.setEnvironmentVariable("refreshToken", data.refresh_token);

tests["token_type is Bearer"] = data.token_type == "Bearer"

;
A noter qu’il y a un test qui contrôle que le token renvoyé est bien de type Bearer. Vous exécutez à nouveau la requête et le test est en vert. Bravo !

Vérification de token

Il existe un endpoint qui permet de récupérer l’identité de l’utilisateur à partir de son access_token. L’appel se fait en GET et au lieu de préciser « en dur » l’access_token dans les paramètres, il est possible d’utiliser la variable d’environnement précédemment enregistrée avec la syntaxe {{accessToken}}.

De plus, histoire d’écrire un test et surtout de vérifier que l’on utilise les bons identifiants, nous avons le test (optionnel) suivant :

var data = JSON.parse(responseBody);

tests["it's my token"] = data.user_login == postman.getGlobalVariable("login");

Renouvellement de token

Vous êtes maintenant expérimenté pour configurer la requête permettant de renouveller le token à partir du refresh_token précédemment enregistré :

Et comme pour la récupération de l’access_token à partir des identifiants de l’utilisateur, il est nécessaire d’écrire le même test pour enregistrer les tokens dans les variables d’environnement.

Appel de l’API

Maintenant que Postman est capable de récupérer un access_token et de le renouveler, il est très simple de configurer des appels d’API sans devoir tout le temps changer la valeur de l’access_token. Vous l’aurez sûrement deviné, il suffit d’ajouter dans tous vos appels d’API l’entête HTTP suivante : Authorization: Bearer {{accessToken}}.

Et le tour est joué !

Conclusion

Sous prétexte de vouloir implémenter le Resource Owner Password Credentials Grant, nous avons pu parcourir un ensemble de notions Postman assez intéressantes :

  • Global variables : pour une configuration commune à tous les appels faits dans Postman
  • Environment variables : pour une configuration spécifique à un environnement mais aussi pour stocker des informations contextuelles
  • Les tests : pour extraire des informations de la réponse, les stockers et réaliser des contrôles
  • Les variables : référencées via des {{}} et utilisables partout (URL, paramètres, entête, body, …)

Nous n’avons pas vu les Pre-request Scripts2 qui permettent de dynamiser la requête (paramètres, payload, etc…). Mais ce sont de simples scripts Javascript exécutés juste avant l’appel de l’API.
Vous êtes donc maintenant armés pour automatiser tous vos tests d’APIs et tout ceci via une interface utilisateur graphique !

  1. Rien n’empêche de les mettre dans des variables d’environnement Postman ↩
  2. C’est le pendant des Tests ↩
https://blog.lecacheur.com/wp-content/uploads/2017/07/postman-logo.pnghttps://blog.lecacheur.com/wp-content/uploads/2017/07/postman-logo-150x150.pngSeBDéveloppementapi,oauth2,testsMême si curl est mon outil préféré pour appeler des APIs, il faut avouer qu'il est parfois plus confortable d'utiliser une IHM telle que Postman. Ce dernier supporte de nombreux modes d'authentification dont l'OAuth2. Cependant, OAuth2 propose 4 types d'autorisation. Or, Postman n'en supporte que 2 actuellement : Authorization...Un blog, c'est un blog !