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.

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
Informations d’identification du client			(application uniquement)
Flux de code d’appareil
Flux implicite
Flux On-Behalf-Of	access token
Nom d'utilisateur/mot de passe (ROPC)	nom d’utilisateur, mot de passe
Circuit OIDC hybride
Échange de jetons d’actualisation	jeton d'actualisation

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 votre consentement à d’autres autorisations d’accès aux ressources.
• Non interactif (silencieux) : l’utilisateur peut ne pas être invité à saisir 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.

Dans le diagramme suivant, l’application :

1. Demande un code d’autorisation, qui a été échangé 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. Certaines bibliothèques et infrastructures demandent le code d’autorisation automatiquement, et 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.0 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

Dans le diagramme suivant, l’application :

1. Obtient 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

Dans le diagramme suivant, l’application :

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

Ces informations d’identification client doivent être :

• Inscrit avec Microsoft Entra ID
• 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.0 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 Microsoft Entra ID 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).

Dans le schéma suivant :

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 :
  • Locataire : https://login.microsoftonline.com/{tenant}/, où {tenant} est soit l’ID du locataire, soit un nom de domaine associé au locataire.
  • Comptes professionnels et scolaires : https://login.microsoftonline.com/organizations/.

Octroi implicite.

Le flux d’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 côté client.

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.0 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).

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.0 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.

Dans le schéma suivant :

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)

L’octroi des informations d’identification de mot de passe du propriétaire des ressources OAuth 2.0 (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.

Dans le diagramme suivant, l’application :

1. Obtient 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 ASP.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.
  • Pour plus d’informations sur ROPC dans MSAL.NET et Azure AD B2C, consultez Utilisation de ROPC avec Azure AD B2C.

Authentification Windows intégrée (IWA)

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

Dans le diagramme suivant, l’application :

1. Obtient 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 et de plateforme universelle Windows.

IWA prend en charge les utilisateurs fédérés AD FS uniquement, c’est à dire les utilisateurs créés dans Active Directory et sécurisés par Microsoft Entra ID. Les utilisateurs créés directement dans Microsoft Entra ID sans support 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 tenant Microsoft Entra et qu’un challenge MFA est émis par Microsoft Entra ID. Si IWA échoue, vous devez revenir à une méthode interactive d’authentification comme décrit précédemment.

Microsoft Entra ID utilise l’IA 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 à tenant unique dont l’audience de connexion est limitée aux utilisateurs du tenant Microsoft Entra 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 multi-tenant dont l’audience de connexion est l’ensemble des utilisateurs dans tout tenant Microsoft Entra.

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 d’accorder leur consentement pour l’utilisation de l’application ; consultez Consentement de l’utilisateur.
• 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.

Étape suivante

Découvrez l’acquisition et la mise en cache des jetons utilisés dans ces flux :