Dans un article précédent, j’ai partagé la configuration du flux OAuth Client Credentials avec Azure AD. La configuration du flux OAuth Authorization Code avec Azure AD est similaire à celle-ci. Elle se réalise directement depuis les interfaces d’Azure AD et ne nécessite pas l’écriture de code. Ce post présente les étapes manuelles pour configurer le flux OAuth Authorization Code avec Azure AD. Néanmoins, sachez qu’il est possible de scripter toutes ces opérations pour les automatiser.
Je ne vais pas décrire les différentes étapes du flux OAuth Authorization Code car il existe d’innombrables articles en ligne. Je vous propose néanmoins celui-ci si vous avez besoin d’informations approfondies : https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow. Contrairement au flux Client Credentials, ce flux est essentiel lorsqu’un utilisateur est impliqué et disponible. En pratique, un personne utilise une application (par exemple une web app) et souhaite accéder à une ressource (par exemple une API). Un tiers de confiance (Identity Provider ou IDP) gère l’autorisation d’accès de l’utilisateur à cette ressource. L’application web doit demander à l’utilisateur de s’authentifier auprès de l’IDP. Au moment de l’authentification, l’utilisateur consent à ce que l’application utilise son identité et ses autorisations pour accéder à la ressource. On parle alors de “délégation d’identité”.
Pour illustrer la manière de procéder sur Azure AD, je vous propose un exemple à partir de 2 applications :
Personnellement, j’ai ajouté 2 App Registrations dans mon Active Directory Azure : la première pour gérer l’identité de mon serveur (API), la seconde, celle de mon client (application web) :
Dans un premier temps, nous allons configurer l’App Registration Serveur (SampleAPIServer). Je vais paramétrer a minima :
Le scope est requis et il va permettre de contrôler la portée sur lequel l’application va pouvoir demander une délégation d’identité. Il ne faut pas oublier que l’application demande à l’utilisateur le droit d’utiliser son identité, et cette utilisation va se limiter à cette portée. Les App Role, quant à eux sont utiles pour déterminer les rôles réel de l’utilisateur sous-jacent.
Le scope se configure sur la section “Expose an API”
Si vous n’avez pas d’URI pour votre App Registration, vous devrez en définir une (pas nécessairement composé d’un GUID). Ensuite, utiliser le bouton “Add a scope” pour ajouter un scope. Le mien se nomme “sales”.
Vous pouvez changer la gestion du consentement de “Admins only” à “Admins and Users” si vous souhaitez que les utilisateurs non Admin puisse consentir à l’utilisation de l’application.
La configuration des App Roles se réalise dans la section “App Roles”
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 faut renseigner un libellé. Ensuite, je choisis le type de membre autorisé à utiliser ce rôle. Pour mettre en place des permissions utilisateurs, il est à minima nécessaire de choisir le type “User”. 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 valider la création du rôle.
La configuration du serveur étant terminé, nous allons configurer l’App Registration Client. Pour ce faire, nous allons paramétrer :
L’url de retour se configure dans la section “Authentication” de l’écran de gestion de l’App Registration. Il est nécessaire d’ajouter une plateforme cible, dans mon cas, j’ai choisi Web.
Veillez à cocher le type de token que vous souhaitez générer lors des demandes d’autorisations (dans mon cas “ID Tokens”)
Il faut autoriser l’application cliente à demander des jetons au nom d’un utilisateur (délégation). Pour faire cela, utilisez l’onglet “API Permissions” sur l’écran de gestion de l’App Registration Client (dans mon cas SampleAPIClient). Ensuite cliquez sur “Add a permission” (Ajouter une autorisation) pour associer un scope à votre application cliente.
Après avoir cliqué sur “Add a permission”, un panneau s’affiche à droite. Retrouvez votre API via ce panneau. Si vous avez ajouté l’App Registration serveur vous-même, vous aurez un accès rapide via l’onglet “My APIs”. Une fois l’API serveur choisie, vous devez choisir le type de permission à donner. Dans notre cas de figure (Authorization code), il est nécessaire de choisir “Delegated”. Vous devez, sur cet écran, choisir les permissions que vous souhaiter accorder à votre client. Ainsi, dans mon exemple, je vais prendre le scope “sales”.
Après avoir validé l’affectation des permissions, un “warning” indique qu’un administrateur doit effectuer une validation. Cliquez sur la commande “Grant Admin Consent” pour confirmer l’association du scope à l’application cliente.
Pour respecter le standard OAuth Authorization Code, l’application cliente 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.
Par ailleurs, le secret du client s’ajoute à partir de l’onglet “Certificates & secrets” (Certificats et secrets) en cliquant sur la commande “New client secret” (Nouveau secret client). De plus, pensez à bien copier-coller ce secret car il ne sera disponible qu’une seule fois sur votre écran. Enfin, notez également que le secret doit avoir une date de péremption afin de garantir une rotation. 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é.
Maintenant que les App Registrations sont initialisées, Il est nécessaire d’attribuer des rôles à des utilisateurs. Ces rôles pourront être utilisés par l’application cliente pour identifier les droits de l’utilisateur. Ces rôles s’attribuent depuis les interfaces Azure AD. Pour réaliser cette manipulation, vous devez vous rendre sur l’écran “Enterprise Applications” d’Azure AD (attention à ne pas confondre avec “App Registrations”). Retrouvez votre Enterprise Application qui correspond à votre serveur et naviguez sur l’onglet “Users And Groups”. Depuis cet écran, vous pouvez ajouter des droits à n’importe quel utilisateur.
Dans mon exemple ci-dessous, je me suis personnellement attribué 2 rôles.
Pour tester la configuration, dans un premier temps, il est nécessaire de demander un code d’autorisation. La documentation détaillé est donnée à l’url https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#request-an-authorization-code. Personnellement, en utilisant un navigateur, j’ai utilisé l’url suivante (remplacez les tokens par les valeurs correspondantes) :
Notez, la présence du paramètre “prompt”. Son effet est de proposer la fenêtre de consentement lors de la première demande de jeton. De plus l’utilisateur devra valider la délégation de son identité à l’application. Sur la capture suivante, l’utilisateur est prévenu que le client “SampleAPIClient” va utiliser la délégation d’identité sur le scope “sales” de l’application “SampleAPIServer.
Une fois l’authentification validé, l’utilisateur est alors redirigé vers l’application cliente (à l’url définit par le paramètre redirect_uri). Le code d’autorisation qui permet de réclamer le jeton JWT est alors transmis en paramètre http. Pour demander l’access token à partir du code, il est nécessaire de faire un POST sur l’url : https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token avec le body suivant :
client_id={client_id}&code={body}&grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A123%2Flogin_callback&scope={scope}&client_secret={client_secret}
En retour, vous obtenez l’access_token. Lorsque je decode le mien, j’observe la présence du user (nom, prénom, email…), du scope et des rôles associés :
