Types d’applications et flux d’authentification de la plateforme d’identités Microsoft

La plateforme d’identités Microsoft prend en charge l’authentification pour différents types d’architectures d’applications modernes. Toutes les architectures sont basées sur les protocoles standard OAuth 2.0 et OpenID Connect. Les bibliothèques d’authentification de la plateforme d’identités Microsoft permettent aux applications d’authentifier les identités et d’acquérir des jetons afin d’accéder aux API protégées.

Cet article décrit les flux d’authentification et les scénarios d’application dans lesquels ils sont utilisés :

Catégories d’applications

Les jetons de sécurité peuvent être obtenus à partir de plusieurs types d’applications, notamment :

• les applications web
• Applications mobiles
• Applications de bureau
• API Web

Les jetons peuvent également être obtenus par les applications qui sont exécutées sur des appareils qui n’ont pas de navigateur ou qui s’exécutent sur IoT.

Les sections suivantes décrivent les catégories d’applications.

Ressources protégées et applications clientes

Les scénarios d’authentification impliquent deux activités :

• Acquisition de jetons de sécurité pour une API web protégée : Nous vous recommandons d’utiliser la bibliothèque MSAL (Microsoft Authentication Library), développée et prise en charge par Microsoft.
• Protection d’une API web ou d’une application web : l’une des tâches les plus complexes dans la protection de ces ressources est la validation du jeton de sécurité. Sur certaines plateformes, Microsoft propose des bibliothèques d’intergiciels (middleware).

Avec utilisateurs ou sans utilisateurs

La plupart des scénarios d’authentification acquièrent des jetons pour le compte d’utilisateurs connectés.

Toutefois, il existe également des applications démon. Dans ces scénarios, les applications acquièrent des jetons pour elles-mêmes, sans intervention de l’utilisateur.

Applications clientes monopages, publiques et confidentielles

Les jetons de sécurité peuvent être acquis par plusieurs types d’applications. On peut diviser ces applications en trois catégories. Chacune est utilisée avec différents objets et bibliothèques.

• Applications monopages : Également appelées « applications SPA », il s’agit d’applications web dans lesquelles les jetons sont acquis par une application JavaScript ou TypeScript qui s’exécute dans le navigateur. De nombreuses applications modernes ont un front-end d’application monopage écrit principalement en JavaScript. L’application utilise souvent un framework comme Angular, React ou Vue. MSAL.js est la seule bibliothèque d’authentification Microsoft prenant en charge les applications monopages.

• Applications clientes publiques : Les applications qui appartiennent à cette catégorie, comme les types d’applications qui suivent, connectent toujours les utilisateurs :

  • Applications de bureau qui appellent des API web pour le compte d’utilisateurs connectés
  • Applications mobiles
  • Applications s’exécutant sur des appareils qui n’ont pas de navigateur, comme ceux qui s’exécutent sur IoT

• Applications clientes confidentielles : Les applications appartenant à cette catégorie sont les suivantes :

  • Applications web qui appellent une API web
  • API web qui appellent une API web
  • Applications démon, même implémentées en tant que service de console tel qu’un démon Linux ou un service Windows

Audience de connexion

les flux d’authentification disponibles diffèrent en fonction de l’audience de connexion. Certains flux sont disponibles uniquement pour les comptes professionnels ou scolaires. D’autres sont disponibles pour les comptes professionnels ou scolaires, et pour les comptes Microsoft personnels.

Pour plus d’informations, consultez l’article Types de comptes pris en charge.

Types d’applications

La plateforme d’identités Microsoft prend en charge l’authentification pour les architectures d’application suivantes :

• Applications monopages
• les applications web
• API Web
• Applications mobiles
• Applications natives
• Applications démon
• Applications côté serveur

Les applications utilisent les différents flux d’authentification pour connecter les utilisateurs et obtenir des jetons pour appeler des API protégées.

Application monopage

De nombreuses applications web modernes sont créées en tant qu’applications monopages côté client. Ces applications utilisent JavaScript ou un framework comme Angular, Vue ou React. Ces applications s’exécutent dans un navigateur web.

Les applications monopages se différencient des applications web traditionnelles côté serveur au niveau des caractéristiques d’authentification. Avec la plateforme d’identités Microsoft, les applications monopages peuvent connecter des utilisateurs et obtenir des jetons pour accéder à des services back-end ou à des API web. La plateforme d’identités Microsoft propose deux types d’autorisation pour les applications JavaScript :

MSAL.js (2.x)	MSAL.js (1.x)

Application web qui connecte un utilisateur

Pour protéger une application web qui connecte un utilisateur :

• Si vous développez en .NET, vous utilisez ASP.NET ou ASP.NET Core avec le middleware OpenID Connect ASP.NET. La protection d’une ressource implique la validation du jeton de sécurité, qui est effectuée par les extensions IdentityModel pour .NET, et non par les bibliothèques MSAL.

• Si vous développez en Node.js, vous utilisez MSAL Node.

Pour plus d’informations, consultez Application web qui connecte les utilisateurs.

Application web qui connecte un utilisateur et appelle une API web pour le compte de l’utilisateur

Pour appeler une API web à partir d’une application web pour le compte d’un utilisateur, utilisez le flux de code d’autorisation et stockez les jetons acquis dans le cache de jetons. Le cas échéant, MSAL actualise les jetons et le contrôleur acquiert en mode silencieux des jetons à partir du cache.

Pour plus d’informations, consultez Application web qui appelle des API web.

Application de bureau qui appelle une API web pour le compte d’un utilisateur connecté

Pour qu’une application de bureau puisse appeler une API web qui connecte des utilisateurs, utilisez les méthodes d’acquisition de jetons interactives des bibliothèques MSAL. Avec ces méthodes interactives, vous pouvez contrôler l’expérience de l’interface utilisateur de connexion. MSAL utilise un navigateur web pour cette interaction.

Il existe une autre possibilité pour les applications hébergées sur Windows qui s’exécutent sur des ordinateurs joints à un domaine Windows ou par Microsoft Entra ID. Ces applications peuvent acquérir un jeton en mode silencieux à l’aide de l’authentification Windows intégrée.

Les applications qui s’exécutent sur un appareil sans navigateur peuvent toujours appeler une API pour le compte d’un utilisateur. Pour s’authentifier, l’utilisateur doit se connecter sur un autre appareil doté d’un navigateur web. Ce scénario nécessite que vous utilisiez le flux de code d’appareil.

Notez que le flux Nom d’utilisateur/Mot de passe est disponible dans les applications clientes publiques, même si nous ne recommandons pas son utilisation. Ce flux est toujours nécessaire dans certains scénarios comme DevOps.

L’utilisation du flux Nom d’utilisateur/Mot de passe contraint vos applications. Par exemple, les applications ne peuvent pas connecter un utilisateur qui doit utiliser l’authentification multifacteur ou l’outil d’accès conditionnel dans Microsoft Entra ID. Vos applications ne bénéficient pas non plus de l’authentification unique. L’authentification à l’aide du flux Nom d’utilisateur/Mot de passe va à l’encontre des principes de l’authentification moderne et n’est fournie que pour des raisons d’héritage.

Dans les applications de bureau, si vous souhaitez que le cache de jetons soit conservé, vous pouvez personnaliser la sérialisation du cache de jetons. En implémentant une double sérialisation du cache de jetons, vous pouvez utiliser des caches de jetons à compatibilité descendante et ascendante.

Pour plus d’informations, consultez Application de bureau qui appelle des API web.

Application mobile qui appelle une API web pour le compte d’un utilisateur interactif

Comme l’application de bureau, l’application mobile appelle les méthodes d’acquisition de jeton interactives MSAL afin d’acquérir un jeton pour appeler une API web.

MSAL iOS et MSAL Android utilisent le navigateur web du système par défaut. Toutefois, vous pouvez leur donner pour instruction d’utiliser l’affichage web incorporé. Il existe des spécificités qui dépendent de la plateforme mobile : Plateforme Windows universelle (UWP), iOS ou Android.

Certains scénarios, comme ceux qui impliquent un accès conditionnel lié à l’identité d’appareil ou à l’inscription de l’appareil, nécessitent l’installation d’un répartiteur sur l’appareil. Le portail d’entreprise Microsoft sur Android et Microsoft Authenticator sur Android et iOS sont des exemples de répartiteurs.

Pour plus d’informations, consultez Application mobile qui appelle des API web.

API web protégée

Vous pouvez utiliser le point de terminaison de la plateforme d’identités Microsoft pour sécuriser des services web, comme l’API RESTful de votre application. Une API web protégée est appelée à l’aide d’un jeton d’accès. Le jeton aide à sécuriser les données de l’API et authentifie les requêtes entrantes. L’appelant d’une API web ajoute un jeton d’accès dans l’en-tête d’autorisation d’une requête HTTP.

Si vous souhaitez protéger votre API web ASP.NET ou ASP.NET Core, validez le jeton d’accès. Pour cette validation, vous utilisez le middleware JWT ASP.NET. La validation est effectuée par la bibliothèque d’extensions IdentityModel pour .NET, non par MSAL.NET.

Pour plus d’informations, consultez API web protégée.

API web qui appelle une autre API web pour le compte d’un utilisateur

Si vous souhaitez que votre API web protégée puisse appeler une autre API web pour le compte d’un utilisateur, votre application doit acquérir un jeton pour l’API web en aval. De tels appels sont parfois qualifiés d’appels de service à service. Les API web qui appellent d’autres API web doivent fournir une sérialisation de cache personnalisée.

Pour plus d’informations, consultez API web qui appelle des API web.

Application démon qui appelle une API web dans le nom du démon

Les applications qui contiennent des processus de longue durée ou qui fonctionnent sans interaction utilisateur doivent également disposer d’un moyen d’accès aux API web sécurisées. Ces applications peuvent s’authentifier et obtenir des jetons à l’aide de leur identité d’application. L’application prouve son identité à l’aide d’un certificat ou d’une clé secrète client.

Vous pouvez écrire des applications démon qui acquièrent un jeton pour l’application appelante à l’aide des méthodes d’acquisition des informations d’identification du client MSAL. Ces méthodes exigent une clé secrète client que vous ajoutez à l’inscription de l’application dans Microsoft Entra ID. L’application partage ensuite le secret avec le démon appelé. Parmi ces secrets, citons par exemple les mots de passe d’application, l’assertion de certificat ou l’assertion du client.

Pour plus d’informations, consultez Application démon qui appelle des API web.

Scénarios et flux d’authentification pris en charge

Vous pouvez utiliser les flux d’authentification pour implémenter les scénarios d’applications qui exigent des jetons. Il n’existe pas de mappage un-à-un entre des scénarios d’applications et des flux d’authentification.

Les scénarios qui impliquent l’acquisition de jetons sont également mappés à des flux d’authentification OAuth 2.0. Pour plus d’informations, consultez Protocoles OAuth 2.0 et OpenID Connect sur la plateforme d’identités Microsoft.

Scénario	Procédure pas à pas de scénario	Flux et octroi OAuth 2.0	Public visé
	Application à page unique	Code d’autorisation avec PKCE	Comptes professionnels ou scolaires, comptes personnels et Azure Active Directory B2C (Azure AD B2C)
	Application à page unique	Implicite	Comptes professionnels ou scolaires, comptes personnels et Azure Active Directory B2C (Azure AD B2C)
	Application web qui connecte les utilisateurs	Code d’autorisation	Comptes professionnels ou scolaires, comptes personnels et Azure AD B2C
	Application web qui appelle des API web	Code d’autorisation	Comptes professionnels ou scolaires, comptes personnels et Azure AD B2C
	Application de bureau qui appelle des API web	Interactif à l’aide de code d’autorisation avec PKCE	Comptes professionnels ou scolaires, comptes personnels et Azure AD B2C
		Authentification Windows intégrée	Comptes professionnels ou scolaires
		Mot de passe de propriétaire de la ressource	Comptes professionnels ou scolaires et Azure AD B2C
	Application sans navigateur	Code d’appareil	Comptes professionnels ou scolaires, comptes personnels mais pas Azure AD B2C
	Application mobile qui appelle des API web	Interactif à l’aide de code d’autorisation avec PKCE	Comptes professionnels ou scolaires, comptes personnels et Azure AD B2C
		Mot de passe de propriétaire de la ressource	Comptes professionnels ou scolaires et Azure AD B2C
	Application démon qui appelle des API web	Informations d’identification du client	Autorisations d’application uniquement, sans utilisateur, et utilisées uniquement dans les organisations Microsoft Entra
	API web qui appelle des API web	On-behalf-of	Comptes professionnels ou scolaires et comptes personnels

Scénarios avec les plateformes et langages pris en charge

Les bibliothèques d’authentification Microsoft prennent en charge plusieurs plateformes :

• .NET
• .NET Framework
• Java
• JavaScript
• macOS
• Android natif
• iOS natif
• Node.js
• Python
• Windows 10/UWP

Vous pouvez également utiliser différents langages pour générer vos applications.

Dans la colonne Windows du tableau suivant, chaque fois que .NET est mentionné, .NET Framework est également possible. Ce dernier est omis pour éviter d’encombrer la table.

Scénario	Windows	Linux	Mac	iOS	Android
Application à page unique	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Application à page unique	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Application web qui connecte les utilisateurs	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node
Application web qui appelle des API web	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node
Application de bureau qui appelle des API web	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node MSAL.objc
Application mobile qui appelle des API web	MSAL.NET MSAL.NET			MSAL.objc	MSAL.Android
Application démon	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node
API web qui appelle des API web	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node

Pour plus d’informations, consultez Bibliothèques d’authentification de plateforme d’identité Microsoft.

Étapes suivantes

Pour plus d'informations sur l’authentification, consultez :

• Authentification ou autorisation
• Jetons d’accès de la plateforme d’identités Microsoft
• Sécurisation de l’accès aux applications IoT