Explorer la bibliothèque d’authentification Microsoft
La Bibliothèque d’authentification Microsoft (MSAL) permet aux développeurs d’acquérir des jetons de sécurité auprès de la plateforme d’identités Microsoft afin d’authentifier les utilisateurs et d’accéder aux API web sécurisées. Il peut être utilisé pour fournir un accès sécurisé à Microsoft Graph, à d’autres API Microsoft, à des APIs web tierces ou à votre propre API web MSAL prend en charge de nombreuses architectures et plateformes d’applications différentes, notamment .NET, JavaScript, Java, Python, Android et iOS.
MSAL vous permet d’obtenir des jetons différentes manières, avec une API cohérente pour plusieurs plateformes. MSAL offre les avantages suivants :
- Ne nécessite pas d’utiliser directement des bibliothèques ou du code OAuth pour le protocole dans votre application.
- Acquiert des jetons pour le compte d’un utilisateur ou d’une application (si applicable à la plateforme).
- Gère un cache de jeton et actualise les jetons pour vous quand ils sont sur le point d’expirer. Vous n’avez pas besoin de gérer l’expiration du jeton.
- Vous aide à spécifier le public auquel vous souhaitez que votre application se connecte.
- Vous permet de configurer votre application à partir de fichiers de configuration.
- Vous permet de dépanner votre application en exposant des exceptions, une journalisation et une télémétrie exploitables.
Types d’application et scénarios
Dans MSAL, un jeton peut être obtenu à partir de plusieurs types d’applications : applications web, API web, applications monopages (JavaScript), applications mobiles et natives, démons et applications côté serveur. MSAL prend en charge les plateformes et les infrastructures listées dans le tableau suivant.
| Bibliothèque | Plateformes et infrastructures prises en charge |
|---|---|
| MSAL pour Android | Android |
| MSAL Angular | Applications à page unique avec infrastructures Angular et Angular.js |
| MSAL pour iOS et macOS | iOS et macOS |
| MSAL Go (préversion) | Windows, macOS, Linux |
| MSAL Java | Windows, macOS, Linux |
| MSAL.js | Infrastructures JavaScript/TypeScript, telles que Vue.js, Ember.js ou Durandal.js |
| MSAL.NET | .NET framework, .NET, .NET MAUI, WINUI, Xamarin Android, Xamarin iOS, plateforme Windows universelle |
| MSAL Node | Applications Web avec Express, applications de bureau avec des applications de console multiplateformes et Electron |
| MSAL Python | Windows, macOS, Linux |
| MSAL React | Applications à page unique avec des bibliothèques React et basées sur React (Next.js, Gatsby.js) |
Flux d’authentification
Le tableau suivant montre quelques-uns des différents flux d’authentification fournis par la bibliothèque d’authentification Microsoft (MSAL). Ces flux peuvent être utilisés dans différents scénarios d’application.
| Flux d’authentification | Active | Types d’applications pris en charge |
|---|---|---|
| Code d’autorisation. | Connexion de l’utilisateur et accès aux API Web pour le compte de l’utilisateur. | Desktop, Mobile, Application monopage (SPA) (nécessite 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 | La connexion de l’utilisateur et l’accès aux API Web pour le compte de l’utilisateur sur des appareils soumis à des contractions d’entrées, tels que des téléviseurs intelligents et des appareils IoT. É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 le code d’autorisation avec PKCE à la place. | 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’obtenir un jeton silencieusement (sans interaction de l’utilisateur avec l’interface utilisateur). | Desktop, Mobile |
Applications clientes publiques et confidentielles
La bibliothèque d’authentification Microsoft (MSAL) définit deux types de clients : les clients publics et les clients confidentiels. Un client est une entité logicielle dotée d’un identificateur unique attribué par un fournisseur d’identité. Les types de clients diffèrent selon leur capacité à s’authentifier en toute sécurité auprès du serveur d’autorisation et à contenir des informations sensibles, d’identité montrant les informations afin qu’elles ne soient pas accessibles ou connues d’un utilisateur dans l’étendue de son accès.
Pour déterminer le caractère public ou confidentiel d’un client donné, nous évaluons la capacité de ce client à prouver son identité au serveur d’autorisation. Cela est important, car le serveur d’autorisation doit avoir confiance dans l’identité du client pour émettre des jetons d’accès.
Les applications clientes publiques, comme les applications de bureau, les API sans navigateur, les applications mobiles et les applications pour navigateur côté client, s’exécutent sur des appareils. La sécurité des secrets d'application n'étant pas garantie avec eux, ils ne peuvent accéder aux API Web qu'au nom de l'utilisateur. Chaque fois que la source, ou le bytecode compilé d’une application donnée, est transmis partout où il peut être lu, désassemblé ou inspecté par des parties non approuvées. Étant donné que ces applications ne prennent en charge que les flux de clients publics et qu’elles ne peuvent pas conserver les secrets définis au moment de la configuration, elles ne peuvent pas avoir de clés secrètes client.
Les applications clientes confidentielles, comme les applications web, les applications API web et les applications de service/démon, s’exécutent sur des serveurs. Considérées comme difficilement accessibles aux utilisateurs ou aux attaquants, elles peuvent conserver de manière satisfaisante les secrets définis au moment de la configuration pour prouver leur identité. L’ID client est exposé via le navigateur web, mais la clé secrète n’est transmise que dans le canal arrière et jamais directement exposée.