Azure AD: ADAL, MSAL?
Quid est ? / Qu’es aquò ?
Ces 2 acronymes sont en réalité les bibliothèques d’authentification Azure Active Directory.
ADAL pour Azure Active Directory Authentication Library et MSAL pour Microsoft Authentication Library permettent aux développeurs d’applications d’authentifier les utilisateurs dans une instance locale d’Active Directory (AD), puis d’obtenir des jetons pour sécuriser les appels d’API. Ces 2 protocoles prennent en en charge les protocoles OAuth 2.0 et OpenID Connect 1.0 standard.
Les jetons reçus de chaque point de terminaison ne sont pas interchangeables. Toutefois, avant de commencer le développement d’une application, il est intéressant de choisir la librairie d’authentification la plus approprié. Nous allons voir dans l’article, quelles sont les points communs, les différences, pourquoi et comment les utiliser…
Pour commencer rien ne vaut un petit schéma:
Historiquement, il n’existait qu’une seule version de bibliothèque d’authentification pour Azure AD: ADAL. Déjà présente dans l’ancien portail et associé à la puissance d’Azure AD, elle permet notamment d’offrir:
- Du SSO avec AD (FS), Office 365, etc…en offrant un contrôle amélioré avec accès conditionnel, du MFA et de la protection de l’identité,
- Accéder à Microsoft Graph ou d’autres API Microsoft,
- D’accéder à des applications présentes dans le store ou développées par les entreprises,
- etc…
Depuis le début de l’année 2017, il existe à présent 2 librairies. Chacune d’elle a ses propres spécificités et les méthodes d’appel sont légèrement différentes: ADAL va utiliser des points de terminaison (endpoint) en V1 et MSAL en V2. A savoir: Le point de terminaison d’origine d’Azure AD V1 est toujours intégralement pris en charge et supporté par Microsoft. À certains égards, il est plus riche en fonctionnalités que le point de terminaison v2.0. Toutefois, le point de terminaison v2.0 présente des avantages significatifs.
Globalement, si l’application doit prendre en charge l’authentification des comptes personnels Microsoft (MSA: Outlook.com, hotmail.com, etc…), il faudra plutôt utiliser les points de terminaison v2.0 et donc la libraire MSAL. Si l’application ne doit prendre en charge l’authentification que des comptes professionnels et scolaires (propre annuaire Azure AD ou autre annuaire Azure AD), il faudra dans ce cas utiliser les points de terminaison en V1 (ADAL). Pour l’instant Microsoft ne permet pas de passer de la V1 à la V2 sans re-développement. Il n’est pas indispensable de migrer surtout que quelques limitations existent encore sur la V2.
ADAL – Azure Active Directory Authentication Library
Portail de gestion et d’ajout d’une application: https://portal.azure.com/
Portail de gestion autorisations et consentements (pour l’utilisateur):
https://myapps.microsoft.com/
Consentement (statique) à la 1ère connexion à l’application:
Dans visual studio, pour utiliser ADAL.NET, vous devez ajouter le NuGet Microsoft.IdentityModel.Clients.ActiveDirectory et utiliser l’espace de noms Microsoft.IdentityModel.Clients.ActiveDirectory
MSAL – Microsoft Authentication Library
Pour rappel: Prise en charge de la connexion avec Azure AD (Work et school) et les comptes Microsoft MSA (Outlook, Hotmail, etc.).
Portail de gestion et d’ajout d’une application: https://apps.dev.microsoft.com/
Contrairement à ADAL, l’application peut utiliser un seul ID d’application pour plusieurs plateformes: Si vous avez déjà utilisé Azure AD, vous avez probablement inscrit plusieurs applications différentes pour un seul et même projet. Par exemple, si vous avez créé un site web et une application iOS, vous avez dû les inscrire séparément, en utilisant deux ID d’application différents. Chaque composant apparaissait comme une application distincte dans Azure AD. Lorsque les utilisateurs donnaient leur consentement pour une application, chaque composant apparaissait dans l’écran de consentement comme une application distincte. Avec le point de terminaison v2.0, vous pouvez maintenant inscrire tous les composants de votre projet comme une seule et même application, et utiliser un ID d’application unique pour l’ensemble du projet.
Portail de gestion autorisations et consentements (pour l’utilisateur) : https://www.microsoft.com/consent
Consentement dynamique et incrémentiel: Il s’agit là d’une nouveauté intéressante! Avec cette fonctionnalité, l’application peut demander des autorisations supplémentaires lors de l’exécution, en jumelant la demande de consentement de l’utilisateur avec la fonctionnalité qui la requiert. L’expérience est beaucoup plus confortable pour les utilisateurs. Ainsi, ils n’ont pas besoin d’accorder une longue liste d’autorisations lors de leur première connexion.
Exemple d’un consentement initial puis un nouveau pour la même application:
Restrictions à fin août 2018 (la liste complète est présente ici):
- API Web autonome : Il est possible d’utiliser le point de terminaison v2.0 pour générer une API web sécurisée avec OAuth 2.0. Toutefois, cette API web peut recevoir uniquement les jetons d’une application ayant le même ID d’application. Il est impossible d’accéder à une API web à partir d’un client qui a un ID d’application différent. Ce client ne pourra pas demander ou obtenir d’autorisation d’accès à l’API web.
- Restrictions sur les inscriptions d’applications: Les applications qui sont inscrites dans portal.azure.com ne s’affichent pas dans le nouveau portail apps.dev.microsoft.com et inversement.
- URI de redirections: Limités à 20, elles doivent partager un seul domaine DNS.
- Protocoles: SAML et WS-Fed ne sont pas supportés (pas de SSO avec ADFS donc). Seuls Open ID Connect et OAuth 2.0 fonctionnent. Certaines fonctionnalités des protocoles OAuth n’ont pas été intégrées dans le point de terminaison v2.
Dans visual studio, pour utiliser MSAL.NET, vous devez ajouter le NuGet Microsoft.Identity.Client et utiliser l’espace de noms Microsoft.Identity.Client
-> Pour aller plus loin avec MSAL et configurer une application exemple, vous pouvez lire l’article en suivant le lien.