Partager via


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 :

Avec utilisateurs ou sans utilisateurs

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

Scénarios avec utilisateurs

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.

Scénarios avec applications démon

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)
Une autorisation pour application monopage Une application monopage implicite

Application web qui connecte un utilisateur

Une 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

Une application web appelant des API web

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.

Une application de bureau appelant une API web

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.

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.

Une application mobile appelant 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.

Remarque

Une application mobile qui utilise MSAL iOS ou MSAL Android peut se voir appliquer des politiques de protection des applications. Par exemple, les stratégies peuvent empêcher un utilisateur de copier du texte protégé. L’application mobile est gérée par Intune et reconnue par Intune en tant qu’application gérée. Pour plus d’informations, consultez l’article Présentation du Microsoft Intune App SDK.

Le SDK d’application Intune est distinct des bibliothèques MSAL et interagit avec Microsoft Entra ID de façon autonome.

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.

Une API web appelant une autre API web

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.

Une application démon appelée par d’autres applications et API

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 monopage avec code d’authentification Application à page unique Code d’autorisation avec PKCE Comptes professionnels ou scolaires, comptes personnels et Azure Active Directory B2C (Azure AD B2C)
Application monopage avec un flux implicite Application à page unique Implicite Comptes professionnels ou scolaires, comptes personnels et Azure Active Directory B2C (Azure AD B2C)
Application web qui connecte les utilisateurs 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 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 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 Application sans navigateur Code d’appareil Comptes professionnels ou scolaires, comptes personnels mais pas Azure AD B2C
Application mobile qui appelle des API web 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 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 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
Autorisation d’application monopage
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js MSAL.js MSAL.js
MSAL.js
Application à page unique
Application monopage implicite
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js MSAL.js MSAL.js
MSAL.js
Application web qui connecte les utilisateurs
Application web qui connecte les utilisateurs
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
Application web qui appelle des API web

Application web qui appelle des API web
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
Application de bureau qui appelle des API web

Application de bureau qui appelle des API web Flux de code d’appareil
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python
MSAL Node
MSAL Node
iOS/Objective C ou Swift MSAL.objc
Application mobile qui appelle des API web
Application mobile qui appelle des API web
UWP MSAL.NET Xamarin MSAL.NET iOS/Objective C ou Swift MSAL.objc Android MSAL.Android
Application démon
Application démon
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NET MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
API web qui appelle des API web

API web qui appelle des API web
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NET
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NET
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
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 :