Erkunden der Microsoft-Authentifizierungsbibliothek
Mit der Microsoft-Authentifizierungsbibliothek (MSAL) können Entwickler Sicherheitstoken von Microsoft Identity Platform abrufen, um Benutzer zu authentifizieren und auf geschützte Web-APIs zuzugreifen. Es kann verwendet werden, um sicheren Zugriff auf Microsoft Graph, andere Microsoft-APIs, Web-APIs von Drittanbietern oder Ihre eigene Web-API MSAL zu ermöglichen, um viele verschiedene Anwendungsarchitekturen und Plattformen wie .NET, JavaScript, Java, Python, Android und iOS zu unterstützen.
MSAL bietet zahlreiche Möglichkeiten für den Tokenabruf und stellt eine konsistente API für viele Plattformen bereit. MSAL bietet folgende Vorteile:
- Die OAuth-Bibliotheken oder Code müssen nicht direkt in Übereinstimmung mit dem Protokoll in Ihrer Anwendung verwendet werden.
- Token werden im Namen eines Benutzers oder einer Anwendung abgerufen (sofern auf die Plattform zutreffend).
- MSAL stellt einen Tokencache bereit und aktualisiert Token, kurz bevor sie ablaufen. Sie müssen sich nicht um den Ablauf von Token kümmern.
- Unterstützt Sie beim Festlegen der Zielgruppe, für die sich Ihre Anwendung anmelden soll.
- Sie können Ihre Anwendung mithilfe von Konfigurationsdateien einrichten.
- Sie können Fehler in Ihrer App mithilfe von handlungsrelevanten Ausnahmen sowie Protokoll- und Telemetriedaten beheben.
Anwendungstypen und -szenarien
In MSAL kann ein Token von verschiedenen Anwendungstypen abgerufen werden: Webanwendungen, Web-APIs, Single-Page-Apps (JavaScript), mobile und native Anwendungen sowie Daemons und serverseitige Anwendungen. MSAL unterstützt derzeit die in der folgenden Tabelle aufgeführten Plattformen und Frameworks.
| Bibliothek | Unterstützte Plattformen und Frameworks |
|---|---|
| MSAL für Android | Android |
| MSAL Angular | Single-Page-Apps mit den Frameworks Angular und Angular.js |
| MSAL für iOS und macOS | iOS und macOS |
| MSAL Go (Vorschau) | Windows, macOS, Linux |
| MSAL Java | Windows, macOS, Linux |
| MSAL.js | JavaScript-/TypeScript-Frameworks wie Vue.js, Ember.js oder Durandal.js |
| MSAL.NET | .NET Framework, .NET, .NET MAUI, WINUI, Xamarin Android, Xamarin iOS, Universelle Windows-Plattform |
| MSAL Node | Web-Apps mit Express, Desktop-Apps mit Electron, plattformübergreifende Konsolen-Apps |
| MSAL Python | Windows, macOS, Linux |
| MSAL React | Single-Page-Apps mit React-Bibliotheken und React-basierten Bibliotheken (Next.js, Gatsby.js) |
Authentifizierungsflows
In der folgenden Tabelle finden Sie einige der verschiedenen Authentifizierungsflows, die von der Microsoft-Authentifizierungsbibliothek (MSAL) bereitgestellt werden. Diese Flows können in verschiedenen Anwendungsszenarien verwendet werden.
| Authentifizierungsfluss | ermöglicht | Unterstützte Anwendungstypen |
|---|---|---|
| Autorisierungscode | Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs zu. | Desktop, Mobil, Einzelseiten-App (SPA) (erfordert PKCE), Web |
| Clientanmeldeinformationen | Zugriff auf Web-APIs mithilfe der Identität der Anwendung selbst. Wird in der Regel für die Kommunikation zwischen Servern und automatisierten Skripts verwendet, die keine Benutzerinteraktion erfordern. | Daemon |
| Gerätecode | Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs auf Geräten mit Eingabebeschränkungen wie Smart-TVs und IoT-Geräte zu. Wird auch von CLI-Anwendungen (Befehlszeilenschnittstelle) verwendet. | Desktop- und Mobilgeräte |
| Implizite Gewährung | Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs zu. Der implizite Zuweisungsflow wird nicht mehr empfohlen. Verwenden Sie stattdessen den Autorisierungscode mit PKCE. | Single-Page-Webanwendung (Single-Page-App, SPA), Web |
| Im Auftrag von (OBO, On-Behalf-Of) | Zugriff einer vorgelagerten Web-API auf eine nachgelagerte Web-API im Namen des Benutzers. Die Identität des Benutzers und die delegierten Berechtigungen werden von der vorgelagerten API an die nachgelagerte API übergeben. | Web-API |
| Benutzername/Kennwort (ROPC) | Ermöglicht es einer Anwendung, den Benutzer durch die direkte Verarbeitung seines Kennworts anzumelden. Der ROPC-Flow wird NICHT empfohlen. | Desktop- und Mobilgeräte |
| Integrierte Windows-Authentifizierung (IWA) | Ermöglicht es Anwendungen auf Computern, die in eine Domäne oder in Microsoft Entra eingebunden sind, automatisch (also ohne Benutzerinteraktion über die Benutzeroberfläche) ein Token abzurufen. | Desktop- und Mobilgeräte |
Öffentliche und vertrauliche Clientanwendungen
Die Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) definiert zwei Arten von Clients: öffentliche und vertrauliche Clients. Ein Client ist eine Softwareentität, die über einen eindeutigen Bezeichner verfügt, der von einem Identitätsanbieter zugewiesen wird. Die Clienttypen unterscheiden sich je nach Möglichkeit, sich sicher mit dem Autorisierungsserver zu authentifizieren und vertrauliche, identitätsbezogene Informationen zu speichern, sodass im Rahmen des Zugriffs auf einen Benutzer nicht zugegriffen oder er bekannt wird.
Bei der Prüfung der öffentlichen oder vertraulichen Art eines bestimmten Clients bewerten wir die Fähigkeit dieses Clients, seine Identität gegenüber dem Autorisierungsserver zu beweisen. Dies ist wichtig, da der Autorisierungsserver der Identität des Clients vertrauen können muss, um Zugriffstoken auszugeben.
Öffentliche Clientanwendungen werden auf Geräten ausgeführt, z. B. auf Desktops, browserlosen APIs, mobilen oder clientseitigen Browser-Apps. Sie sind in Bezug auf eine sichere Speicherung von Anwendungsgeheimnissen nicht vertrauenswürdig und können daher nur im Namen eines Benutzers auf Web-APIs zugreifen. Wenn die Quelle oder der kompilierte Bytecode einer bestimmten App überall übertragen wird, kann sie von nicht vertrauenswürdigen Parteien gelesen, zerlegt oder anderweitig geprüft werden. Da sie auch nur Flows für öffentliche Clients unterstützen und keine Konfigurationszeitgeheimnisse enthalten können, können sie nicht über geheime Clientschlüssel verfügen.
Vertrauliche Clientanwendungen werden auf Servern ausgeführt, wie z. B. Web-Apps, Web-API-Apps oder Dienst-/Daemon-Apps. Sie gelten als für Benutzer oder Angreifer schwer zugänglich und können daher Konfigurationszeitgeheimnisse angemessen verwahren, um den Nachweis ihrer Identität zu bestätigen. Die Client-ID wird über den Webbrowser verfügbar gemacht, aber der geheime Schlüssel wird nur im Rückkanal übergeben und niemals direkt verfügbar gemacht.