Intégrer une application à Azure AD (MSAL) et authentification avec OpenID Connect
Petit rappel sur le protocole OAuth 2.0 et la couche OpenID Connect (dans le contexte AZURE AD)
OpenID Connect (OIDC) est une simple couche d’identification basée sur le protocole OAuth 2.0 (Protocole d’autorisation). Avec OpenID Connect, outre un jeton d’accès, les applications peuvent également obtenir un jeton d’identification auprès d’Azure AD. Les jetons d’identification OpenID Connect contiennent des revendications sur l’identité de l’utilisateur et des informations sur la méthode et le lieu d’authentification. Des flux OpenID Connect sont généralement utilisés par les applications web. Ces applications peuvent utiliser le jeton d’identification pour personnaliser leur comportement avec l’utilisateur pour lequel elles ont demandé un jeton d’accès. Et, dans de nombreux cas vont externaliser la connexion de leurs utilisateurs à Azure AD et activer des expériences comme l’authentification unique (SSO).
OAuth 2.0 est un protocole d’autorisation. Il définit la façon dont les applications peuvent accéder aux jetons d’accès par une authentification directe à Azure Active Directory ou par la redirection d’un utilisateur pour une authentification auprès d’Azure AD et l’acceptation des autorisations requises par votre application.
- Dans le premier cas, votre application obtient un jeton d’accès qu’elle peut utiliser pour appeler une API.
- Dans le deuxième cas, les applications obtiennent un jeton d’accès qu’elle peuvent utiliser pour appeler une API au nom d’un utilisateur.
Cependant, avec OAuth 2.0, l’application ne reçoit pas d’informations sur l’utilisateur ou sur l’authentification par Azure AD. Des flux OAuth 2.0 sont généralement utilisés par des applications mobiles ou natives qui connaissent déjà l’identité de l’utilisateur, ou par des applications comme les services d’arrière-plan ou les démons, qui appellent des API sous leur propre identité et non au nom d’un utilisateur.
Le scénario se base à partir des sources présentes sur le Github Microsoft. Comme indiqué dans le titre de cet article nous allons utiliser la libraire MSAL (Endpoint V2). Pour un scénario avec la librairie ADAL, vous pouvez suivre le lien présent plutot sur ce Github Microsoft. Pour connaitre les différences entres ces deux librairies vous pouvez consulter l’article ci après: https://remivernier.com/index.php/2018/09/03/azure-ad-adal-msal/
Inscription de l’application
Dans notre scénario, nous allons nous authentifier dans un premier temps avec un compte MSA (Pour rappel, MSAL permet par défaut à n’importe quel compte MSA de s’authentifier une application utilisant cette librairie). Dans un second temps nous verrons une authentification plus classique avec un compte présent dans un tenant Azure AD.
L’inscription de l’application ne s’effectue pas classiquement sur le portail Azure. Nous allons utiliser la nouvelle librairie MSAL et l’inscription s’effectue donc sur le portail d’enregistrement des applications: https://apps.dev.microsoft.com/
Le nom de l’application est « remiapp ». Une fois l’application crée, un ID de l’application est alors affecté (il faudra noter cette valeur car nous en auront besoin plus tard pour la configuration de l’application).
Un certain nombres d’options s’affichent alors.
Vous noterez que les autorisation déléguées pour Microsoft Graph sont pré-enregistrée: « User.Read ». Pour notre application se sera suffisant.
Notez que nous n’ajoutons pas d’autorisations supplémentaires, comme nous le ferions avec ADAL (Endpoint V1). La fonction de consentement incrémentiel et dynamique de MSAL (Endpoint V2) a rendu cette étape facultative.
Il existe deux types d’autorisations :
- Les autorisations déléguées sont utilisées par les applications qui s’exécutent avec les droits de l’utilisateur connecté. Ces droits sont délégués à l’application qui appelle une API au nom de l’utilisateur. De nombreuses autorisations peuvent être consenties par l’utilisateur, mais d’autres nécessitent le consentement de l’administrateur.
- Les autorisations de l’application sont utilisées par les applications qui s’exécutent sans utilisateur (daemon, service, etc…). Ces autorisations accordent généralement à l’application de nombreux droits qui peuvent êtres particulièrement dangereux. Elles nécessitent toujours l’autorisation d’un administrateur.
Nous allons ensuite générer un nouveau mot de passe pour l’application via le bouton « Générer un nouveau mot de passe » afin de générer et de stocker un secret partagé dans le magasin de données respectif, que vous pouvez utiliser dans votre application. il faudra aussi le noter car il ne s’affiche qu’une fois et ensuite seuls les 3 premiers caractères sont présents.
Toute application doit utiliser un secret d’application pour s’identifier auprès d’Azure AD lors de l’échange du jeton de sécurité. Chaque application peut contenir à tout moment deux mots de passe valide, cela permet de renouveler le mot de passe sans interruption de service.
Le bouton « Générer une nouvelle paire de clés » permet de créer une paire de clés publique/privée qui peut être téléchargée et utilisée pour l’authentification du client auprès d’Azure AD. Le bouton « Télécharger la clé publique » permet d’utiliser notre propre paire de clés publique/privée.
Grace à MSAL, et c’est une grande nouveauté, l’application peut utiliser un seul ID d’application pour plusieurs plateformes. Nous pourrions donc ajouter une plateforme WEB et Native dans la même application. Dans notre cas nous avons besoin uniquement d’une application Web:
L’URL de redirection correspond à l’URL vers lequel le navigateur doit être redirigé après la phase d’authentification. L’URL saisie est https://localhost:44326/ celle ci est l’URL par défaut sur laquelle l’application va s’exécuter avec Visual Studio.
La case à cocher « Autoriser le flux implicite » est coché par défaut. Dans un flux implicite, l’application reçoit des jetons directement d’Azure AD, sans aucun échange de serveur à serveur. Tout le traitement de l’authentification et de la gestion des sessions est entièrement exécuté dans le client par un code JavaScript, sans redirections de pages supplémentaires.
Des options supplémentaires nous permettent de définir un profil pour l’application. Nous allons ajouter l’URL de la page d’accueil afin de voir l’application sur le portail: https://www.microsoft.com/consent
L’application est à présent enregistrée, nous allons passer à la configuration de celle ci.
Création de l’application dans visual studio
Ouvrir le projet sous Visual Studio: active-directory-dotnet-webapp-openidconnect-v2.sln
La seule configuration a effectuer dans notre projet se trouve dans le Web.config. Les éléments à renseigner sont le ClientID et ClientSecret précédemment générés:
Exécuter ensuite le projet. Comme vous pouvez le constater au lancement de l’application le bouton nous indique que nous pouvons nous authentifier avec un compte Microsoft. Une des force de MSAL est que nous pouvons ici nous authentifier avec un compte Microsoft MSA OU un compte issu d’un annuaire Azure.
Compte MSA:
Compte Azure:
