Prise en charge du flux d’authentification dans MSAL

La bibliothèque d’authentification Microsoft (MSAL) prend en charge plusieurs octrois d’autorisation et des flux de jetons associés pour une utilisation par différents types d’applications et scénarios.

Flux d’authentification Active Types d’applications pris en charge
Code d’autorisation Connexion de l’utilisateur et accès aux API Web pour le compte de l’utilisateur. * Bureau
* Mobile
* Application monopage (SPA) (requiert PKCE)
* Web
Informations d’identification du client Accès aux API Web à l’aide de l’identité de l’application elle-même. Généralement utilisé pour la communication de serveur à serveur et les scripts automatisés ne nécessitant aucune intervention de l’utilisateur. Démon
Code d’appareil La connexion de l’utilisateur et l’accès aux API Web pour le compte de l’utilisateur sur des appareils soumis à des contractions d’entrées, tels que des téléviseurs intelligents et des appareils IoT. Également utilisé par les applications d’interface de ligne de commande (CLI). Desktop, Mobile
Octroi implicite Connexion de l’utilisateur et accès aux API Web pour le compte de l’utilisateur. Le flux d’octroi implicite n’est plus recommandé : utilisez le code d’autorisation avec PKCE à la place. * Application monopage (SPA)
* Web
Flux OBO Accès à partir d’une API Web « en amont » à une API Web « en aval » pour le compte de l’utilisateur. L’identité de l’utilisateur et les autorisations déléguées sont transmises à l’API en aval à partir de l’API en amont. API Web
Nom d'utilisateur/mot de passe (ROPC) Permet à une application de connecter l’utilisateur en gérant directement son mot de passe. Le flux ROPC N’est PAS recommandé. Desktop, Mobile
Authentification Windows intégrée (IWA) Permet aux applications sur des ordinateurs joints à un domaine ou à Azure Active Directory (Azure AD) d’obtenir un jeton silencieusement (sans interaction de l’utilisateur avec l’interface utilisateur). Desktop, Mobile

Jetons

Votre application peut utiliser un ou plusieurs flux d’authentification. Chaque flux utilise certains types de jetons pour l’authentification, l’autorisation et l’actualisation des jetons, tandis que d’autres utilisent également un code d’autorisation.

Action ou flux d’authentification Nécessite Jeton d’ID Access token (Jeton d’accès) Jeton d’actualisation Code d’autorisation.
Flux du code d’autorisation x x x x
Informations d’identification du client x (application uniquement)
Flux de code d’appareil x x x
Flux implicite x x
Flux On-Behalf-Of access token x x x
Nom d'utilisateur/mot de passe (ROPC) nom d’utilisateur, mot de passe x x x
Circuit OIDC hybride x x
Échange de jetons d’actualisation jeton d'actualisation x x x

Authentification interactive et non interactive

Plusieurs de ces flux prennent en charge l’acquisition interactive et non interactive de jetons.

  • Interactif : l’utilisateur peut être invité à entrer des données par le serveur d’autorisation. Par exemple, pour vous connecter, effectuez l’authentification multifacteur (MFA) ou accordez un consentement à d’autres autorisations d’accès aux ressources.
  • Non interactif : l’utilisateur peut ne pas être invité à entrer des données. Également appelée acquisition de jetons « en mode silencieux », l’application tente d’obtenir un jeton à l’aide d’une méthode dans laquelle le serveur d’autorisation peut ne pas inviter l’utilisateur à entrer des données.

Votre application basée sur MSAL doit d’abord essayer d’acquérir un jeton en mode silencieux et revenir à une méthode interactive uniquement si la tentative non interactive échoue. Pour plus d’informations sur ce modèle, consultez Acquérir et mettre en cache des jetons à l’aide de Microsoft Authentication Library (MSAL).

Code d’autorisation.

L'octroi de code d’autorisation OAuth 2.0 peut être utilisé par les applications Web, les applications monopage (SPA) et les applications natives (mobiles et de bureau) pour accéder aux ressources protégées telles que les API Web.

Lorsque les utilisateurs se connectent à des applications Web, l’application reçoit un code d’autorisation qu’elle peut accepter pour qu’un jeton d’accès appelle des API Web.

Diagram of authorization code flow

Dans le diagramme ci-dessus, l’application :

  1. Demande un code d’autorisation, qui est accepté contre un jeton d’accès.
  2. Utilise le jeton d’accès pour appeler une API Web, Microsoft Graph.

Contraintes pour le code d’autorisation

  • Les applications monopage nécessitent Proof Key for Code Exchange (PKCE) lors de l’utilisation du flux d’octroi de code d’autorisation. PKCE est pris en charge par MSAL.

  • La spécification OAuth 2.0 requiert l’utilisation d’un code d’autorisation pour accepter un jeton d’accès une seule fois.

    Si vous tentez d’acquérir un jeton d’accès plusieurs fois avec le même code d’autorisation, une erreur semblable à la suivante est retournée par la plateforme d’identités Microsoft. N’oubliez pas que certaines bibliothèques et infrastructures demandent le code d’autorisation automatiquement et que demander un code manuellement dans de tels cas entraînera également cette erreur.

    AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Informations d'identification du client

Le flux d’informations d’identification du client OAuth 2 vous permet d’accéder aux ressources hébergées sur le web à l’aide de l’identité d’une application. Ce type d’octroi est couramment utilisé pour les interactions de serveur à serveur qui doivent s’exécuter en arrière-plan sans l’interaction immédiate d’un utilisateur. Ces types d’application sont souvent appelés démons (daemons) ou comptes de service.

Le flux d’octroi des informations d’identification du client permet à un service web (un client confidentiel) d’utiliser ses propres informations d’identification pour s’authentifier lorsqu’il appelle un autre service web, au lieu d’emprunter l’identité d’un utilisateur. Dans ce scénario, le client est généralement un service web de niveau intermédiaire, un service démon ou un site web. Pour augmenter le niveau d’assurance, la plateforme d’identités Microsoft autorise également le service d’appel à utiliser un certificat (au lieu d’un secret partagé) comme une information d’identification.

Secrets de l’application

Diagram of confidential client with password

Dans le diagramme ci-dessus, l’application :

  1. Acquiert un jeton à l’aide d’un secret d’application ou d’informations d’identification avec mot de passe.
  2. Utilise le jeton pour effectuer des demandes sur la ressource.

Certificats

Diagram of confidential client with cert

Dans le diagramme ci-dessus, l’application :

  1. Acquiert un jeton à l’aide d’informations d’identification de certificat.
  2. Utilise le jeton pour effectuer des demandes sur la ressource.

Ces informations d’identification client doivent être :

  • Inscrites auprès d’Azure AD.
  • Transmises lors de la construction de l’objet de l’application cliente confidentielle dans votre code.

Contraintes pour les informations d’identification du client

Le flux de client confidentiel n’est pas pris en charge sur les plateformes mobiles comme Android, iOS ou UWP. Les applications mobiles sont considérées comme des applications clientes publiques qui ne peuvent pas garantir la confidentialité de leurs informations d’identification.

Code d’appareil

Le flux de code d’appareil OAuth 2 permet aux utilisateurs de se connecter à des appareils à entrée limitée, par exemple des télévisions connectées, des appareils IoT et des imprimantes. L’authentification interactive avec Azure AD nécessite un navigateur web. Lorsque l’appareil ou le système d’exploitation ne propose pas de navigateur web, le flux de code d’appareil permet à l’utilisateur d’utiliser un autre appareil (par exemple un ordinateur ou un téléphone mobile) pour se connecter de manière interactive.

En utilisant le flux de code d’appareil, l’application obtient les jetons via un processus en deux étapes, conçu pour ces appareils et systèmes d’exploitation. De telles applications incluent par exemple celles qui s’exécutent sur des appareils IoT et des outils d’interface de ligne de commande (CLI).

Diagram of device code flow

Dans le diagramme ci-dessus :

  1. Chaque fois que l’authentification de l’utilisateur est nécessaire, l’application fournit un code et invite l’utilisateur à utiliser un autre appareil comme un smartphone connecté à Internet pour accéder à une URL (par exemple, https://microsoft.com/devicelogin). L’utilisateur est ensuite invité à entrer le code ; son expérience se poursuit avec une authentification normale, présentant des invites de consentement et une authentification multifacteur si nécessaire.
  2. Après une authentification réussie, l’application de ligne de commande reçoit les jetons requis via un canal arrière et les utilise pour effectuer les appels d’API web dont il a besoin.

Contraintes pour le code de l’appareil

  • Le flux de code de l’appareil est disponible uniquement sur les applications clientes publiques.
  • Lorsque vous initialisez une application cliente publique dans MSAL, utilisez l’un des formats d’autorité suivants :
    • Avec locataire : https://login.microsoftonline.com/{tenant}/,{tenant} est le GUID représentant l’ID de locataire ou un nom de domaine associé au locataire.
    • Comptes professionnels et scolaires : https://login.microsoftonline.com/organizations/.

Octroi implicite.

L'octroi implicite a été remplacé par le flux de code d'autorisation avec PKCE comme flux d'octroi de jeton préféré et plus sécurisé pour les applications à page unique (SPA) côté client. Si vous créez une SPA, utilisez le flux de code d’autorisation avec PKCE à la place.

Les applications web monopage écrites en JavaScript (y compris les infrastructures comme Angular, Vue.js ou React.js) sont téléchargées à partir du serveur et leur code s’exécute directement dans le navigateur. Étant donné que le code côté client s’exécute dans le navigateur et non sur un serveur web, elles présentent des caractéristiques de sécurité différentes de celles des applications web traditionnelles côté serveur. Avant la disponibilité de Proof Key for Code Exchange (PKCE) pour le flux de code d’autorisation, le flux d’octroi implicite a été utilisé par l’application monopage pour améliorer la réactivité et l’efficacité dans l’obtention des jetons d’accès.

Le flux d’octroi implicite OAuth 2 permet à l’application d’obtenir des jetons de la plateforme d’identités Microsoft sans échanger les informations d’identification du serveur principal. Le flux d’octroi implicite permet à une application de se connecter à l’utilisateur, de maintenir une session et d’obtenir des jetons pour d’autres API web à partir du code JavaScript téléchargé et exécuté par l’agent utilisateur (généralement un navigateur web).

Diagram of implicit grant flow

Contraintes pour l’octroi implicite

Le flux d’octroi implicite n’inclut pas les scénarios d’application qui utilisent des infrastructures JavaScript inter-plateformes comme Electron ou React Native. Les infrastructures inter-plateformes telles que celles-ci nécessitent des fonctionnalités supplémentaires pour l’interaction avec les plateformes de bureau et mobiles natives sur lesquelles elles s’exécutent.

Les jetons émis via le mode de flux implicite comportent une limite de longueur car ils sont retournés au navigateur par URL (où response_mode est query ou fragment). Certains navigateurs limitent la longueur de l’URL dans la barre de navigateur et génèrent une erreur si l’URL est trop longue. Par conséquent, ces jetons de flux implicite ne contiennent pas de revendications groups ou wids.

Flux OBO

Le flux d’authentification On-Behalf-Of OAuth 2 est utilisé lorsqu’une application appelle un service ou une API web, qui à son tour doit appeler un autre service ou une autre API web. L’idée est de propager l’identité et les autorisations de l’utilisateur délégué via la chaîne de la demande. Pour que le service de niveau intermédiaire puisse faire des demandes authentifiées au service en aval, il doit sécuriser un jeton d’accès de la plateforme d’identité Microsoft pour le compte de l’utilisateur.

Diagram of on-behalf-of flow

Dans le diagramme ci-dessus :

  1. L’application acquiert un jeton d’accès pour l’API web.
  2. Un client (application web, de bureau, mobile ou monopage) appelle une API web protégée, en ajoutant le jeton d’accès comme porteur dans l’en-tête d’authentification de la requête HTTP. L’API web authentifie l’utilisateur.
  3. Lorsque le client appelle l’API web, cette dernière demande un autre jeton pour le compte de l’utilisateur.
  4. L’API web protégée utilise ce jeton pour appeler une APIweb en aval pour le compte de l’utilisateur. L’API web pourra également ultérieurement demander des jetons pour les autres API en aval (mais toujours pour le compte du même utilisateur).

Nom d'utilisateur/mot de passe (ROPC)

Avertissement

Le flux des informations d’identification du mot de passe du propriétaire de la ressource (ROPC) n’est PAS recommandé. ROPC requiert un niveau élevé de confiance et expose considérablement les informations d'identification. Utilisez ROPC uniquement si un flux plus sécurisé ne peut pas être utilisé. Pour plus d’informations, consultez l’article sur la solution aux problèmes croissants associés aux mots de passe.

L’octroi des informations d’identification de mot de passe du propriétaire des ressources OAuth 2 (ROPC) permet à une application de connecter l’utilisateur en gérant directement son mot de passe. Dans votre application de bureau, vous pouvez utiliser le flux de nom d’utilisateur/mot de passe pour acquérir un jeton silencieusement. Aucune interface utilisateur n’est requise lorsque vous utilisez l’application.

Certains scénarios d’application comme DevOps peuvent trouver ROPC utile, mais vous devez l’éviter dans toute application dans laquelle vous fournissez une interface utilisateur interactive pour la connexion de l’utilisateur.

Diagram of the username/password flow

Dans le diagramme ci-dessus, l’application :

  1. Acquiert un jeton en envoyant le nom d’utilisateur et le mot de passe au fournisseur d’identité.
  2. Appelle une API web en utilisant le jeton.

Pour obtenir un jeton en mode silencieux sur des ordinateurs joints à un domaine Windows, nous recommandons d’utiliser une authentification Windows intégrée (IWA) au lieu de ROPC. Pour les autres scénarios, utilisez le flux de code de l’appareil.

Contraintes pour ROPC

Les contraintes suivantes s’appliquent aux applications utilisant le flux ROPC :

  • L’authentification unique n’est pas prise en charge.
  • L’authentification multifacteur (MFA) n’est pas pris en charge.
    • Vérifiez auprès de votre administrateur de locataire avant d’utiliser ce flux – MFA est une fonctionnalité couramment utilisée.
  • L’accès conditionnel n’est pas pris en charge.
  • ROPC fonctionne uniquement pour les comptes professionnels et scolaires.
  • Les comptes Microsoft personnels (MSA) ne sont pas pris en charge par ROPC.
  • ROPC est pris en charge dans les applications de bureau .NET et .NET Core.
  • ROPC n’est pas pris en charge dans les applications de plateforme Windows universelle (UWP).
  • ROPC dans Azure AD B2C est pris en charge uniquement pour les comptes locaux.

Authentification Windows intégrée (IWA)

MSAL prend en charge l’authentification Windows intégrée (IWA) pour les applications de bureau et mobiles qui s’exécutent sur des ordinateurs Windows joint à un domaine ou à Azure AD. En utilisant l’authentification Windows intégrée, ces applications acquièrent un jeton silencieusement sans interaction de l’utilisateur avec l’interface utilisateur.

Diagram of integrated Windows authentication

Dans le diagramme ci-dessus, l’application :

  1. Acquiert un jeton à l’aide de l’authentification Windows intégrée.
  2. Utilise le jeton pour effectuer des demandes sur la ressource.

Contraintes pour IWA

Compatibilité

L’authentification Windows intégrée (IWA) est activée pour les applications de bureau .NET, .NET Core et de plateforme universelle Windows.

L’authentification Windows intégrée prend en charge les utilisateurs fédérés AD FS uniquement – les utilisateurs créés dans Active Directory et enregistrés dans Azure AD. Les utilisateurs créés directement dans Azure AD, sans sauvegarde Active Directory (utilisateurs managés) ne peuvent pas utiliser ce flux d’authentification.

Authentification multifacteur (MFA)

L’authentification non interactive (silencieuse) d’IWA peut échouer si l’authentification multifacteur est activée dans le locataire Azure AD et qu’un challenge MFA est émis par Azure AD. Si IWA échoue, vous devez revenir à une méthode interactive d’authentification comme décrit précédemment.

Azure AD utilise l’intelligence artificielle pour déterminer si l’authentification à deux facteurs est requise. L’authentification à 2 facteurs est généralement nécessaire quand un utilisateur se connecte à partir d’un autre pays ou d’une autre région, lorsqu’il est connecté à un réseau d’entreprise sans utiliser de VPN et parfois lorsqu’il est connecté via un VPN. Étant donné que la fréquence des challenges et de la configuration de l’authentification multifacteur peut être hors de votre contrôle en tant que développeur, votre application doit normalement gérer un échec d’acquisition du jeton silencieux d’IWA.

Restrictions d’URI d’autorité

L’autorité transmise lors de la construction de l’application cliente publique doit être l’une des suivantes :

  • https://login.microsoftonline.com/{tenant}/ – Cette autorité indique une application à locataire unique dont l’audience de connexion est limitée aux utilisateurs du locataire Azure AD spécifié. La valeur {tenant} peut être l’ID de locataire sous forme de GUID ou le nom de domaine associé au locataire.
  • https://login.microsoftonline.com/organizations/ – Cette autorité indique une application multilocataire dont l’audience de connexion est les utilisateurs d’un locataire Azure AD.

Les valeurs d’autorité ne doivent PAS contenir /common ou /consumers, car les comptes Microsoft personnels (MSA) ne sont pas pris en charge par IWA.

Exigence du consentement

Étant donné qu’IWA est un flux silencieux :

  • L’utilisateur de votre application doit avoir précédemment donné son consentement pour utiliser l’application.

    OR

  • L’administrateur de locataires doit avoir précédemment consenti à ce que tous les utilisateurs dans la locataire utilisent l’application.

Pour satisfaire l’une ou l’autre des exigences, l’une de ces opérations doit avoir été effectuée :

  • En tant que développeur d’application, vous avez choisi l’option Accorder dans le portail Azure pour vous-même.
  • Un administrateur de locataires a sélectionné Accorder/révoquer le consentement administrateur pour {domaine du locataire} dans l’onglet Autorisations de l’API lors de l’inscription de l’application dans le portail Azure ; consultez Ajouter des autorisations pour accéder à votre API web.
  • Vous avez fourni un moyen aux utilisateurs de donner leur consentement pour l’utilisation de l’application ; consultez Demande de consentement d’utilisateur individuel.
  • Vous avez fourni un moyen à l’administrateur de locataires de donner son consentement pour l’utilisation de l’application ; consultez Consentement administrateur.

Pour plus d’informations sur le consentement, consultez Autorisations et consentement.

Étapes suivantes

Maintenant que vous avez examiné les flux d’authentification pris en charge par MSAL, découvrez comment acquérir et mettre en cache les jetons utilisés dans ces flux :

Acquérir et mettre en cache des jetons à l’aide de Microsoft Authentication Library (MSAL)