Prześledź proces logowania aplikacji internetowej Java

Ten przewodnik śledzi żądanie logowania za pomocą ilustrującego kodu Java serwletu. Wyjaśniono w nim, w jaki sposób przeglądarka, Microsoft Entra ID, MSAL4J i pomocnicy sesji aplikacji wchodzą w interakcje.

Identyfikowanie pomocników zdefiniowanych przez aplikację

Biblioteka MSAL4J udostępnia interfejsy API do uzyskiwania tokenów. Aplikacja dostarcza otaczający kod, który koordynuje przekierowania przeglądarki, przetwarzanie wywołań zwrotnych i sesje. Fragmenty używają tych ilustracyjnych pomocników:

Te nazwy i ich metody pomocnicze są definiowane przez aplikację, a nie interfejsy API MSAL4J. Ich role zostały wyjaśnione w przewodniku, ale ich implementacje nie są uwzględniane.

Adres URL autoryzacji rozpoczyna interakcję przeglądarki

Pierwszy fragment pokazuje, jak aplikacja tworzy adres URL autoryzacji i przekierowuje przeglądarkę. Moduł pomocniczy udostępnia skonfigurowanego klienta poufnego. Aplikacja wygenerowała również nowe, nieprzewidywalne state i nonce wartości dla tego żądania logowania i zachowała je do późniejszego porównania.

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 opisuje identyfikator URI wywołania zwrotnego, żądany zakres uprawnień i opcje protokołu. Collections.singleton jest tu odpowiednia, ponieważ Config.SCOPES zawiera jeden zakres, a nie rozdzielaną spacją listę wielu zakresów. Biblioteka MSAL domyślnie dodaje standardowe zakresy OpenID Connect openid, profile i offline_access.

W przypadku biblioteki MSAL4J 1.9.1 ResponseMode.QUERY parametry odpowiedzi autoryzacji są umieszczane w ciągu zapytania wywołania zwrotnego. Prompt.SELECT_ACCOUNT żąda wyboru konta. state Pomaga skorelować odpowiedź z żądaniem logowania, a token nonce identyfikatora jest powiązany z tym żądaniem.

getAuthorizationRequestUrl tworzy adres URL; redirectUser to pomocnik zdefiniowany przez aplikację, który przekierowuje przeglądarkę. Żadna z operacji nie wykorzystuje kodu autoryzacyjnego.

Funkcja zwrotna wymienia kod na tokeny

Po pomyślnej odpowiedzi autoryzacyjnej Microsoft Entra ID przekierowuje przeglądarkę do URI wywołania zwrotnego aplikacji z kodem autoryzacyjnym. Poniższy fragment koncentruje się na realizacji po tym, jak wywołanie zwrotne zweryfikowało state, obsłużyło odpowiedzi błędów i wyodrębniło authCode. Nie pokazuje pełnej implementacji callbacka.

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 łączy otrzymany kod z URI zwrotnym i żądanym zakresem uprawnień. URI przekierowania musi być zgodny z tym użytym w żądaniu autoryzacji oraz z tym w rejestracji aplikacji. Poufny klient uwierzytelnia aplikację podczas wymiany kodu w punkcie końcowym tokenu.

acquireToken zwraca obiekt future, a .get() czeka na jego rezultat w tym przykładzie. Pomyślna realizacja powoduje utworzenie elementu IAuthenticationResult; nieudana wymiana musi zostać obsłużona jako błąd. Kody autoryzacji to krótkotrwałe i pojedyncze, niezdatne do wielokrotnego użytku poświadczenia dla późniejszych wywołań interfejsu API.

Aplikacja kojarzy wynik z sesją

Następny fragment ilustruje granicę między odbieraniem tokenów a traktowaniem sesji jako uwierzytelnionej. Tutaj element context jest wystąpieniem IdentityContextData zdefiniowanym przez aplikację.

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

Pierwsze wywołanie udostępnia deklaracje tokenu ID na potrzeby weryfikacji wartości nonce przez aplikację. Zdefiniowany przez aplikację pomocnik validateNonce porównuje zwrócony nonce z wartością zachowaną dla oryginalnego żądania i przerywa przetwarzanie, jeśli walidacja się nie powiedzie. Ostatnie wywołanie rejestruje wynik uwierzytelniania oraz zserializowaną pamięć podręczną tokenów w kontekście aplikacji, który otaczający kod wiąże z sesją.

Ci pomocnicy nie zastępują szerszych obowiązków związanych z zabezpieczeniami aplikacji. Kompletna implementacja wymaga również poprawnego przetwarzania odpowiedzi, bezpiecznego magazynu sesji i pamięci podręcznej tokenów, odpowiedniej obsługi błędów i autoryzacji na potrzeby operacji chronionych.

Połącz przepływ

Przeglądarka przeprowadza użytkownika przez proces logowania i zwraca kod autoryzacyjny. Serwer wymienia ten kod autoryzacyjny za pomocą biblioteki MSAL4J, przetwarza wynik i utrzymuje sesję aplikacji. Późniejsze wywołania do Microsoft Graph używają tokenu dostępu, a nie kodu autoryzacji ani tokenu ID.

Aby uzyskać więcej informacji na temat interfejsów API biblioteki, zobacz Konstruktor adresu URL kodu autoryzacji MSAL4J i Uzyskiwanie tokenów przy użyciu kodów autoryzacji.