Avec Azure Active Directory, la plateforme d’identité Microsoft supporte différents flux d’authentification. La configuration du flux d’authentification OAuth Client Credentials est réalisable directement depuis les interfaces Azure AD. Il n’est pas nécessaire d’écrire une seule ligne de code pour cette configuration. Dans ce post, je vous partage la configuration minimale nécessaire pour réaliser ce type de gestion des accès.
Mon objectif n’est pas de décrire le grant type Client Credentials en détail, mais plutôt de montrer comment le paramétrer sur Azure AD. D’ailleurs, vous trouverez d’innombrables schémas et explications sur Internet concernant le fonctionnement de ce flux (par exemple https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow). Néanmoins, je rappelle juste que ce flux est incontournable lorsqu’il s’agit de gérer les autorisations d’accès entre machines (machine-à-machine). Cette cinématique d’autorisation est donc à considérer uniquement lorsqu’il n’y a pas d’utilisateurs à authentifier. Par exemple, lorsqu’une application souhaite accéder à une API sous son identité applicative, ce flux prend tout son sens.
Pour illustrer la manière de procéder sur Azure AD, je vous propose comme exemple :
Personnellement, j’ai ajouté 2 App Registrations sur mon Active Directory Azure : la première pour gérer l’identité de mon serveur (API), la seconde, celle de mon client (application) :
Pour cet exemple, j’ai configuré 2 App Registrations mono-tenant, mais l’opération fonctionne également avec des App Registrations multi-tenant.
Dans un premier temps, nous allons configurer l’App Registration Serveur (SampleAPIServer). Je vais simplement avoir besoin de préciser les rôles qu’il est possible d’affecter à une application. Sous Azure AD, les rôles d’une App Registration se nomment “App Roles” (ou « rôles d’application » en français). Pour configurer ces App Roles via les interfaces, il est nécessaire de se rendre sur la page d’accueil de l’App Registration, et de cliquer sur l’onglet “App roles”.
Sur l’écran suivant, je configure la liste des rôles proposées par mon App Registration. Personnellement, je m’inspire souvent de l’organisation et des conventions de la Graph REST API pour structurer mes propres API. Je vais faire de même dans cet exemple en définissant 3 rôles.
Pour créer un App Role, utilisez la commande “Create app role” (Créer un rôle d’application). Un panneau sur la droite de votre écran apparaît. Dans ce panneau, il est nécessaire de renseigner un libellé. Ensuite, je choisis le type de membre autorisé à utiliser ce rôle. Pour mettre en place des permissions d’applications, il est a minima nécessaire de choisir le type “Applications”. Sur la capture ci-dessus, je sélectionne “Both”, qui inclut les utilisateurs et les applications. Mon rôle pourra dès lors être affecté à un utilisateur et/ou à une application.
Donnez ensuite une valeur à ce rôle. Cette valeur est celle qui sera transmise dans le jeton JWT. Il n’est pas obligatoire que le libellé soit identique à la valeur. Finalement, donnez une description du rôle pour pouvoir valider l’insertion.
Dans une première étape, nous avons configuré les App Roles que propose notre serveur. Maintenant, il faut affecter les permissions que nous souhaitons accorder à notre client. Cette fois-ci, il est nécessaire d’utiliser l’onglet “API permissions” au niveau de l’écran de gestion de l’App Registration Client (SampleAPIClient). Via cet écran, utilisez la commande “Add a permission” (Ajouter une autorisation) pour associer un rôle à votre application cliente.
Après avoir cliqué sur “Add a permission”, un panneau s’affiche à droite. Retrouvez votre App Registration Serveur via ce panneau. Si vous avez ajouté cette dernière vous-même, vous aurez un accès rapide via l’onglet “My APIs”. Une fois l’App Registration Serveur choisie, vous devez choisir le type de permission à donner. Dans notre cas de figure (Client Credentials), il est nécessaire de choisir “Application permissions” (Autorisations d’application). Vous devez, sur cet écran, choisir les permissions que vous accordez à votre client. Pour mon exemple, je vais prendre les 2 droits en lecture que nous avons définis plus haut.
Après avoir validé l’affectation des permissions, une icône de type “warning” vous indiquera que malgré l’affectation des permissions au client, les rôles ne sont pas encore accordés. En effet, dès lors qu’il s’agit d’un flux machine-à-machine, il n’y aura pas d’intervention utilisateur au moment de l’authentification. Il est nécessaire qu’un administrateur donne son accord pour l’affectation de ces droits depuis ces interfaces.
Pour donner votre accord, utilisez la commande “Grant admin consent for <your tenant>” (Accorder un consentement d’administrateur pour <votre tenant>) comme indiqué sur la capture ci-dessus.
Pour respecter le standard OAuth Client Credentials, l’App Registration Client doit fournir un ID et un secret client afin d’obtenir un jeton JWT. L’ID du client se récupère via l’écran “Overview” (Vue d’ensemble) au niveau de l’App Registration Client.
Le secret du client peut se créer à partir de l’onglet “Certificates & secrets” (Certificats et secrets) en cliquant sur la commande “New client secret” (Nouveau secret client). Attention à bien copier-coller ce secret car il ne sera disponible qu’une seule fois sur votre écran. Notez également que le secret doit avoir une date de péremption afin de garantir une rotation de celui-ci. Par défaut, Microsoft recommande une expiration à 6 mois. Il est essentiel de définir des durées de vie raisonnables pour garder un haut niveau de sécurité. Il vous faudra donc gérer l’expiration de ces secrets.
Lorsque vous demandez un token, vous devez fournir le scope pour lequel vous demandez celui-ci. Ce scope représente généralement l’élément sur lequel vous demandez vos autorisations. Donc, en tant que client, si vous souhaitez obtenir un token sur l’application SampleAPIServer, vous devez fournir le scope correspondant à l’application SampleAPIServer. Par défaut, si vous n’avez pas défini d’application ID URI, vous devez utiliser une valeur qui est la concaténation de votre identifiant d’application avec “/.default”. Vous aurez donc comme résultat quelque chose de la forme “<Guid>/.default”.
Encore une fois, la plateforme d’identité Microsoft respecte le standard OAuth en proposant les endpoints normés. Pour obtenir un jeton JWT, il suffit de réaliser une requête POST conformément à la norme OAuth. Vous trouverez ci-dessous un exemple :
POST /<tenant-id>/oauth2/v2.0/token HTTP/1.1 Host: login.microsoftonline.com Content-Type: application/x-www-form-urlencoded Content-Length: 179 grant_type=client_credentials&client_id=<client-id>&client_secret=<client-secret>&scope=<scope>
Pour effectuer cette requête, vous devez fournir, d’une part, le scope, l’ID client et le secret, et d’autre part, vous devez pousser cette requête (POST HTTP) sur votre tenant. Vous aurez donc besoin de l’identifiant de votre tenant.
Si je teste mon scénario, je retrouve bien les éléments comme l’issuer (émetteur du token), l’audience (l’ID de l’App Registration cible) et les rôles qui me sont attribués.
