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