Grundlegendes zur Anmeldung mit MSAL4J

Abgeschlossen

MSAL4J verbindet die Anwendungskonfiguration mit Microsoft Identity Platform Authentifizierungs- und Tokenerfassungs-APIs. In dieser Lektion wird ein Clientkonstruktionsbeispiel und die Rolle der Bibliothek im Anmeldefluss einer Webanwendung erläutert.

Microsoft-Authentifizierungsbibliothek für Java

Mit dem Microsoft-Authentifizierungsbibliothek für Java (MSAL4J) können Anwendungen sich mit Microsoft Identitäten authentifizieren und Token für geschützte APIs abrufen. Es unterstützt Szenarien mit Microsoft Entra ID, persönlichen Microsoft-Konten und Azure AD B2C unter Verwendung von OAuth 2.0 und OpenID Connect.

Note

Vorhandene Azure AD B2C-Kunden können den Dienst weiterhin nutzen. Es ist seit dem 1. Mai 2025 noch nicht für den Kauf durch neue Kunden verfügbar, und der Support wird bis mindestens Mai 2030 fortgesetzt. Azure AD B2C P2 wurde für alle Kunden am 15. März 2026 eingestellt. Der fortlaufende Servicesupport deckt keine eingestellten P2-Features ab.

Verwenden Sie für neue Kundenidentitätsprojekte Microsoft Entra External ID. Das Szenario in diesem Modul behandelt einen Microsoft Entra-Mandanten für die Belegschaft, nicht einen Azure AD B2C-Mandanten oder einen externen External ID-Mandanten. Ausführliche Informationen finden Sie in den häufig gestellten Fragen zum Azure AD B2C- End-of-Sale.

MSAL4J unterstützt verschiedene Anwendungstypen, darunter Webanwendungen, Hintergrunddienste, Befehlszeilenanwendungen und Desktopanwendungen. Der entsprechende Clienttyp und der Tokenakquisitionsfluss hängen von der Umgebung der Anwendung ab.

Ein vertraulicher Client stellt die Serveranwendung dar.

MSAL unterscheidet öffentliche Clients, die Anwendungsanmeldeinformationen nicht zuverlässig vertraulich halten können, von vertraulichen Clients, die sich mit sicher gehaltenen Anmeldeinformationen authentifizieren können. Eine serverseitige Java Webanwendung ist ein vertraulicher Client.

Das folgende illustrative Fragment konstruiert diesen Client. Die großgeschriebenen Namen sind Konfigurationsplatzhalter, keine tatsächlichen Kennungen oder Geheimwerte. Importe, umgebender Anwendungscode und Ausnahmebehandlung werden nicht angezeigt.

IClientCredential credential = ClientCredentialFactory.createFromSecret(CLIENT_SECRET);
ConfidentialClientApplication app = ConfidentialClientApplication
                                        .builder(CLIENT_ID, credential)
                                        .authority(AUTHORITY)
                                        .build();

Das Fragment verbindet drei Eingaben:

Input Bedeutung
CLIENT_ID Der Anwendungsbezeichner aus der Registrierung.
CLIENT_SECRET Ein Platzhalter für geheimes Material, das dem Server bereitgestellt wird. Dies zeigt eine Factory für Anmeldeinformationen, nicht die Aufforderung, ein Geheimnis zu erstellen oder einzubetten.
AUTHORITY Die URL des Identitätsanbieters und die Anmeldegruppe. Im Szenario mit einem Mandanten wird der ausgewählte Microsoft Entra-Mandant ermittelt.

ClientCredentialFactory erstellt ein Anmeldeinformationsobjekt, und der Builder ordnet dieses Anmeldeinformationsobjekt der Client-ID und der Authority der Anwendung zu. Der Aufruf von build() erstellt den MSAL-Client; dabei wird kein Benutzer angemeldet und der Browser auch nirgendwohin weitergeleitet.

Rolle von MSAL im Autorisierungscodefluss

Ein vertraulicher Client authentifiziert die Anwendung, während die Browserinteraktion den Benutzer authentifiziert. Die Anwendung koordiniert diese Teile des Flusses:

Phase MSAL-API Anwendungsverantwortung
Browseranmeldung starten getAuthorizationRequestUrl Erstellen Sie eine Autorisierungsanforderung, und leiten Sie den Browser dorthin um.
Einlösen eines Autorisierungscodes acquireToken mit AuthorizationCodeParameters Verarbeiten Sie den Rückruf, überprüfen Sie die Antwort, und tauschen Sie den empfangenen Code für Token aus.
Token für einen späteren API-Aufruf abrufen acquireTokenSilently mit SilentParameters Geben Sie das Konto und den entsprechenden Tokencachekontext an, und behandeln Sie Fälle, die eine Benutzerinteraktion erfordern.

Für diese Webanwendung empfängt der Rückruf einen Autorisierungscode, nicht das Microsoft Graph Zugriffstoken. Die Codeeinlösung erfolgt über eine Server-zu-Server-Anforderung an den Tokenendpunkt.

Interpretieren des Authentifizierungsergebnisses

Beim erfolgreichen Einlösen eines Codes wird ein IAuthenticationResult zurückgegeben. In diesem OpenID Connect-Szenario stellt das Ergebnis ein ID-Token für die Anwendung und ein Zugriffstoken für die angeforderte API bereit. Außerdem werden Informationen bereitgestellt, die zum Verwalten der Konto- und Tokenlebensdauer verwendet werden.

Das ID-Token enthält Identitätsansprüche; Das Zugriffstoken ermöglicht eine Anforderung an die beabsichtigte API. Ein ID-Token ist kein Ersatz für ein Microsoft Graph Zugriffstoken. MSAL4J erwirbt Token, aber die Anwendung oder ein API-spezifisches SDK führt den nachfolgenden Geschäfts-API-Aufruf aus.

Die nächste Einheit veranschaulicht diese Aufgaben anhand von kommentiertem Servlet-Code. Die MSAL-Übersicht bietet zusätzlichen Kontext zu unterstützten Szenarien und tokenverwaltung.