Flux d’authentification pris en charge dans MSAL
Microsoft Authentication Library (MSAL) prend en charge plusieurs octrois d’autorisation et flux de jetons associés pour une utilisation par différents types et scénarios d’application.
| Flux d’authentification | Active | Types d’applications pris en charge |
|---|---|---|
| Code d’autorisation | Connexion 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 | Connexion utilisateur et accès aux API web pour le compte de l’utilisateur sur les appareils avec contrainte d’entrée, tels que les téléviseurs intelligents et les appareils IoT (Internet des objets). É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 plutôt le code d’autorisation avec la clé de preuve pour l’échange de code (PKCE). | * 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 à Microsoft Entra ID d’acquérir un jeton en mode silencieux (sans aucune interaction de l’interface utilisateur de l’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 | ✅ | ✅ | ✅ | ✅ | |
| Informations d’identification du client | ✅ (application uniquement) | ||||
| Flux de code d’appareil | ✅ | ✅ | ✅ | ||
| Flux implicite | ✅ | ✅ | |||
| Flux On-Behalf-Of | Access token (Jeton d’accès) | ✅ | ✅ | ✅ | |
| 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 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 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.
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 ci-dessus, l’application :
- Demande un code d’autorisation, qui est accepté contre un jeton d’accès.
- Utilise le jeton d’accès pour appeler une API web, telle que 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 similaire à ce qui suit est retournée par le 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 serveur à serveur (S2S) qui doivent s’exécuter en arrière-plan, sans interaction immédiate d’un utilisateur. Ces types d’applications sont souvent appelés démons ou services.
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 ci-dessus, l’application :
- Acquiert un jeton à l’aide d’un secret d’application ou d’informations d’identification de mot de passe.
- Utilise le jeton pour effectuer des demandes de ressources.
Certificats
Dans le diagramme ci-dessus, l’application :
- Acquiert un jeton à l’aide d’informations d’identification de certificat.
- Utilise le jeton pour effectuer des demandes de ressources.
Ce type d’informations d’identification client doit ê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 client confidentiel n’est pas pris en charge sur les plateformes mobiles telles qu’Android, iOS ou plateforme Windows universelle (UWP). Les applications mobiles sont considérées comme des applications clientes publiques incapables de garantir la confidentialité des secrets d’authentification.
Code d’appareil
Le flux de code d’appareil OAuth 2 permet aux utilisateurs de se connecter à des appareils limités en entrée tels que des téléviseurs intelligents, des appareils IoT (Internet des objets) 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 fournit pas de navigateur web, le flux de code de l’appareil permet d’utiliser un autre appareil, tel qu’un ordinateur ou un téléphone mobile, de 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.
Dans le diagramme ci-dessus :
- 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 et passe par une expérience d’authentification normale, y compris les invites de consentement et l’authentification multifacteur, si nécessaire. - Une fois l’authentification réussie, l’application demandant reçoit les jetons requis du Plateforme d’identités Microsoft et les utilise pour effectuer les appels d’API web dont elle 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 :
- Basé sur le locataire :
https://login.microsoftonline.com/{tenant}/,où{tenant}se trouve 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/.
- Basé sur le locataire :
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).
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 multiplateformes comme 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 ont une limitation de longueur, car ils sont retournés au navigateur dans l’URL (où response_mode se trouve l’une ou fragmentl’autrequery). 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 de flux d’authentification OAuth 2 pour le compte est utilisé lorsqu’une application appelle un service ou une API web qui, à son tour, doit appeler un autre service ou UNE API web à l’aide d’une identité d’utilisateur et d’autorisations déléguées qui doivent se propager via la chaîne de requêtes. Pour que le service de niveau intermédiaire effectue des demandes authentifiées auprès du service en aval, il doit sécuriser un jeton d’accès à partir du Plateforme d’identités Microsoft pour le compte de l’utilisateur demandeur.
Dans le diagramme ci-dessus :
- L’application acquiert un jeton d’accès pour l’API web.
- 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.
- Lorsque le client appelle l’API web, l’API web demande un autre jeton pour le compte de l’utilisateur.
- L’API web protégée utilise ce jeton pour appeler une API web 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 ROPC (Resource Owner Password Credentials) n’est plus recommandé. ROPC requiert un niveau élevé de confiance et expose considérablement les informations d'identification. Utilisez uniquement ROPC 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 utiles, mais vous devez l’éviter dans toute application dans laquelle vous fournissez une interface utilisateur interactive pour la connexion utilisateur.
Dans le diagramme ci-dessus, l’application :
- Acquiert un jeton en envoyant le nom d’utilisateur et le mot de passe au fournisseur d’identité.
- Appelle une API web en utilisant le jeton.
Pour acquérir un jeton en mode silencieux sur des machines jointes à un domaine Windows, nous vous recommandons d’utiliser le Gestionnaire de comptes web (WAM) 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 .NET Desktop et .NET.
- ROPC n’est pas pris en charge dans les applications de plateforme Windows universelle (UWP).
- ROPC dans ID externe Microsoft Entra est pris en charge uniquement pour les comptes locaux.
- Pour plus d’informations sur ROPC dans MSAL.NET et ID externe Microsoft Entra, consultez Informations d’identification de mot de passe du propriétaire de la ressource (ROPC) avec B2C.
Authentification Windows intégrée (IWA)
Remarque
L’authentification Windows intégrée a été remplacée par un moyen plus fiable d’obtenir des jetons silencieusement - WAM. WAM peut connecter l’utilisateur Windows actuel en mode silencieux. Ce flux de travail ne nécessite pas de configuration complexe et fonctionne même pour les comptes personnels (Microsoft). En interne, le Répartiteur Windows (WAM) essaiera plusieurs stratégies pour obtenir un jeton pour l’utilisateur Windows actuel, y compris IWA et échangeant le PRT. Cela élimine la plupart des limitations avec IWA.
MSAL prend en charge les Authentification Windows intégrés (IWA) pour les applications de bureau et mobiles qui s’exécutent sur des ordinateurs Windows joints à un domaine ou Microsoft Entra ID. 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 ci-dessus, l’application :
- Acquiert un jeton à l’aide de l’authentification Windows intégrée.
- Utilise le jeton pour effectuer des demandes de ressources.
Contraintes pour IWA
- Compatibilité. L’Authentification Windows intégré (IWA) est activé pour les applications .NET Desktop, .NET et plateforme Windows universelle (UWP). IWA prend uniquement en charge les utilisateurs fédérés ADFS : les utilisateurs créés dans Active Directory et soutenus par l’ID Microsoft Entra. 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) peut échouer si l’authentification multifacteur est activée dans le locataire Microsoft Entra ID et qu’une demande MFA est émise par l’ID Microsoft Entra. 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 configuration et la fréquence des défis de l’authentification multifacteur peuvent être en dehors de votre contrôle en tant que développeur, votre application doit gérer correctement une défaillance de l’acquisition de jetons silencieux IWA.
- Restrictions d’URI d’autorité. L’autorité passée 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 monolocataire dont l’audience de connexion est limitée aux utilisateurs du locataire Microsoft Entra ID 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 des utilisateurs dans n’importe quel locataire Microsoft Entra ID.
- Comptes personnels. Les valeurs d’autorité ne doivent pas contenir
/commonou/consumersparce que les comptes Microsoft personnels (MSA) ne sont pas pris en charge par IWA. - Conditions de consentement. Étant donné que IWA est un flux silencieux, l’utilisateur de votre application doit avoir précédemment accepté d’utiliser l’application ou l’administrateur du locataire doit avoir précédemment consenti à tous les utilisateurs du locataire pour utiliser l’application. Pour répondre à l’une ou l’autre exigence, l’une de ces opérations doit avoir été effectuée :
- Vous, en tant que développeur d’applications, avez sélectionné Grant 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 à l’application ; consultez Vue d’ensemble des autorisations et du consentement dans le Plateforme d’identités Microsoft.
- Vous avez fourni un moyen pour l’administrateur du locataire de donner son consentement pour l’application ; consultez Vue d’ensemble des autorisations et du consentement dans le Plateforme d’identités Microsoft.
É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.