Verfolgen eines Java Web App-Anmeldeablaufs

  • 7 Minuten

Diese Schritt-für-Schritt-Anleitung verfolgt eine Anmeldeanfrage anhand eines beispielhaften Java-Servlet-Codes. Es wird erläutert, wie der Browser, Microsoft Entra ID, MSAL4J und die Sitzungshilfsprogramme der Anwendung interagieren.

Note

Diese Fragmente sind keine vollständige Anwendung oder eine produktionsbereite Implementierung. Sie lassen den umgebenden Servletcode, Importe, Konfiguration und einige Fehlerbehandlungen aus, um sich auf den Fluss zu konzentrieren. Es muss keine Anwendung erstellt oder ausgeführt werden, um diese Einheit abzuschließen.

Identifizieren der anwendungsdefinierten Hilfsprogramme

MSAL4J stellt die Tokenakquisitions-APIs zur. Die Anwendung stellt den umgebenden Code bereit, der Browserumleitungen, Rückrufverarbeitung und Sitzungen koordiniert. Die Fragmente verwenden diese veranschaulichenden Hilfsfunktionen:

Helfer Rolle in den Beispielen
Config Liefert Anwendungseinstellungen. REDIRECT_URI stellt den registrierten Callback-URI dar, und SCOPES enthält den einzigen Microsoft Graph-Bereich User.Read.
getConfidentialClientInstance und AuthHelper.getConfidentialClientInstance Ein konfiguriertes ConfidentialClientApplication zurückgeben.
contextAdapter Verbindet die HTTP-Anforderung und antwort auf den Sitzungskontext der Anwendung. Die redirectUser Methode leitet den Browser um.
IdentityContextData und context Enthält Daten, die einer Anmeldeanforderung und einer Sitzung zugeordnet sind, einschließlich der Nonce, Token-Claims, des Authentifizierungsergebnisses und des serialisierten Token-Cache.

Diese Namen und ihre Hilfsmethoden sind anwendungsdefiniert, nicht MSAL4J-APIs. Ihre Rollen werden in der exemplarischen Vorgehensweise erläutert, aber ihre Implementierungen sind nicht enthalten.

Eine Autorisierungs-URL startet die Browserinteraktion.

Das erste Fragment zeigt, wie die Anwendung eine Autorisierungs-URL erstellt und den Browser umleitet. Der Helfer liefert einen konfigurierten vertraulichen Client. Die Anwendung hat auch frische, unvorhersehbare state und nonce Werte für diese Anmeldeanforderung generiert und für einen späteren Vergleich aufbewahrt.

final ConfidentialClientApplication client = getConfidentialClientInstance();
AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters
                                                    .builder(Config.REDIRECT_URI, Collections.singleton(Config.SCOPES))
                                                    .responseMode(ResponseMode.QUERY)
                                                    .prompt(Prompt.SELECT_ACCOUNT)
                                                    .state(state)
                                                    .nonce(nonce)
                                                    .build();

final String authorizeUrl = client.getAuthorizationRequestUrl(parameters).toString();
contextAdapter.redirectUser(authorizeUrl);

AuthorizationRequestUrlParameters beschreibt den Rückruf-URI, den angeforderten Bereich und die Protokolloptionen. Collections.singleton ist hier angemessen, da Config.SCOPES einen Scope enthält und keine durch Leerzeichen getrennte Liste mehrerer Scopes. MSAL fügt standardmäßig die OpenID Connect-Bereiche openid, profile und offline_access hinzu.

Mit MSAL4J 1.9.1 platziert ResponseMode.QUERY die Parameter der Autorisierungsantwort in der Queryzeichenfolge des Callbacks. Prompt.SELECT_ACCOUNT fordert die Kontoauswahl an. state hilft, die Antwort mit der Anmeldeanforderung zu korrelieren, während nonce das ID-Token an diese Anforderung gebunden wird.

Note

Ab MSAL4J 1.24.0 ist ResponseMode.QUERY veraltet. Wird dieser Wert übergeben, ersetzt AuthorizationRequestUrlParameters.Builder.responseModeResponseMode.FORM_POST und protokolliert eine Warnung. Dies ist eine Änderung des Bibliotheksverhaltens; Microsoft Entra unterstützt weiterhin Antworten auf Autorisierungscodeantworten im Abfragemodus auf Protokollebene.

Bei Antworten auf Formular-POSTs muss ein Servlet-Callback eine POST-fähige Verarbeitung unterstützen, z. B. doPost, statt sich nur auf doGet zu verlassen. Die Callback-Verarbeitung muss weiterhin die zugeordnete Sitzung, state- und nonce-Validierung sowie die Fehlerbehandlung beibehalten. Das alleinige Ändern des Antwortmodus-Enums deckt diese Verantwortlichkeiten nicht ab.

getAuthorizationRequestUrl erstellt die URL; redirectUser ist das anwendungsdefinierte Hilfsprogramm, das den Browser umleitet. Kein Vorgang löst einen Autorisierungscode ein.

Important

Die dargestellte Anforderung enthält bei der Anmeldung delegierte User.Read von Microsoft Graph. Eine Zustimmungsaufforderung wird nur angezeigt, wenn die Zustimmung erforderlich ist, und die Mandantenrichtlinie ermöglicht es dem Benutzer, die Zustimmung zu erteilen; Eine vorherige Zustimmung des Benutzers oder Administrators kann bedeuten, dass keine Eingabeaufforderung angezeigt wird. Eine Meldung über die Genehmigung eines Administrators erforderlich gibt an, dass ein autorisierter Administrator die Anforderung über den genehmigten Prozess der Organisation überprüfen muss. Die entsprechende Antwort besteht nicht darin, die mandantenweite Zustimmungsrichtlinie zu schwächen. Siehe Benutzer- und Administratorzustimmung.

Der Rückruf wechselt einen Code für Token.

Nach einer erfolgreichen Autorisierungsantwort leitet Microsoft Entra ID den Browser an die Callback-URI der Anwendung mit einem Autorisierungscode um. Das folgende Fragment behandelt die Einlösung, nachdem der Callback state validiert, Fehlerantworten verarbeitet und authCode extrahiert hat. Die gesamte Rückrufimplementierung wird nicht angezeigt.

final AuthorizationCodeParameters authParams = AuthorizationCodeParameters
                                                    .builder(authCode, new URI(Config.REDIRECT_URI))
                                                    .scopes(Collections.singleton(Config.SCOPES))
                                                    .build();

final ConfidentialClientApplication client = AuthHelper.getConfidentialClientInstance();
final IAuthenticationResult result = client.acquireToken(authParams).get();

AuthorizationCodeParameters verbindet den empfangenen Code mit dem Rückruf-URI und dem angeforderten Bereich. Der Umleitungs-URI muss mit dem in der Autorisierungsanforderung und der App-Registrierung verwendeten übereinstimmen. Der vertrauliche Client authentifiziert die Anwendung beim Austausch des Codes am Tokenendpunkt.

acquireToken gibt eine Zukunft zurück und .get() wartet auf das Ergebnis in diesem Beispiel. Eine erfolgreiche Einlösung ergibt ein IAuthenticationResult; ein fehlgeschlagener Umtausch muss als Fehler behandelt werden. Autorisierungscodes sind kurzlebig und nur einmal verwendbar, keine wiederverwendbaren Anmeldeinformationen für spätere API-Aufrufe.

Note

Für neue Implementierungen folgen Sie den aktuellen Richtlinien für den Autorisierungscodefluss: Microsoft empfiehlt proof Key for Code Exchange (PKCE) für alle Anwendungstypen, einschließlich vertraulicher Web-Apps. PKCE ist für Einzelseitenanwendungen (SINGLE Page Applications, SPAs) erforderlich, ist jedoch keine Plattformanforderung für die hier dargestellte vertrauliche Web-App.

Die hier gezeigten expliziten MSAL4J-URL-Konstruktions- und Codeeinlösungs-APIs generieren keine PKCE-Eingaben automatisch. Generieren Sie für jede Anmeldeanfrage einen neuen, unvorhersehbaren Verifier und speichern Sie ihn sicher für den zugehörigen Callback. Geben Sie im Authorization-Request-Builder die daraus mit S256 abgeleitete Challenge als codeChallenge an und setzen Sie codeChallengeMethod("S256"); geben Sie im Redemption-Builder das passende codeVerifier an. PKCE ersetzt weder die Client-Authentifizierung noch die Validierung von state und nonce. Die obigen Fragmente enthalten diese PKCE-Eingaben nicht.

Die Anwendung ordnet das Ergebnis einer Sitzung zu.

Das nächste Fragment veranschaulicht die Grenze zwischen dem Empfangen von Token und der Behandlung einer Sitzung als authentifiziert. context Hier ist eine anwendungsdefinierte IdentityContextData Instanz.

context.setIdTokenClaims(result.idToken());
validateNonce(context);
context.setAuthResult(result, client.tokenCache().serialize());

Der erste Aufruf macht die ID-Token-Claims für die Nonce-Validierung der Anwendung verfügbar. Die anwendungsdefinierte validateNonce Hilfsfunktion vergleicht die zurückgegebene Nonce mit dem für die ursprüngliche Anfrage gespeicherten Wert und beendet die Verarbeitung, wenn die Validierung fehlschlägt. Der letzte Aufruf zeichnet das Authentifizierungsergebnis und den serialisierten Tokencache im Anwendungskontext auf, den der umgebende Code der Sitzung zuordnet.

Diese Helfer ersetzen nicht die umfassenderen Sicherheitsaufgaben der Anwendung. Eine vollständige Implementierung benötigt auch die richtige Antwortverarbeitung, sichere Sitzungs- und Tokencachespeicherung, geeignete Fehlerbehandlung und Autorisierung für geschützte Vorgänge.

Flow verbinden

Der Browser führt den Benutzer durch die Anmeldung und gibt einen Autorisierungscode zurück. Der Server löst diesen Code mit MSAL4J ein, verarbeitet das Ergebnis und verwaltet die Sitzung der Anwendung. Später verwenden Microsoft Graph Aufrufe ein Zugriffstoken, nicht den Autorisierungscode oder das ID-Token.

Weitere Informationen zu den Bibliotheks-APIs finden Sie im URL-Generator für MSAL4J-Autorisierungscode und beim Abrufen von Token mit Autorisierungscodes.