Een aanmeldingsstroom voor Java-web-app traceren

Deze stapsgewijze uitleg volgt een aanmeldverzoek aan de hand van voorbeeldcode voor Java-servlets. Hierin wordt uitgelegd hoe de browser, Microsoft Entra ID, MSAL4J en de sessiehulp van de toepassing communiceren.

De door de toepassing gedefinieerde helpers identificeren

MSAL4J levert de api's voor token-overname. De toepassing levert de omringende code waarmee browseromleidingen, callbackverwerking en sessies worden gecoördineerd. De fragmenten gebruiken deze illustratieve helpers:

Deze namen en hun helpermethoden zijn toepassingsgedefinieerde, niet MSAL4J-API's. Hun rollen worden uitgelegd in het scenario, maar hun implementaties zijn niet opgenomen.

Een autorisatie-URL start browserinteractie

Het eerste fragment laat zien hoe de toepassing een autorisatie-URL maakt en de browser omleidt. De helper levert een geconfigureerde vertrouwelijke client. De toepassing heeft ook nieuwe, onvoorspelbare state en nonce waarden gegenereerd voor deze aanmeldingsaanvraag en deze bewaard voor latere vergelijking.

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 beschrijft de callback-URI, aangevraagd bereik en protocolopties. Collections.singleton is hier geschikt omdat Config.SCOPES het één bereik bevat, in plaats van een door spaties gescheiden lijst met meerdere bereiken. MSAL voegt standaard OpenID Connect-bereiken openidtoe profileen offline_access standaard.

Met MSAL4J 1.9.1 ResponseMode.QUERY plaatst u de parameters voor autorisatiereacties in de queryreeks van de callback. Prompt.SELECT_ACCOUNT vraagt om accountselectie. state helpt het antwoord te correleren met de aanmeldingsaanvraag, terwijl nonce het id-token aan die aanvraag wordt gekoppeld.

getAuthorizationRequestUrl bouwt de URL; redirectUser is de door de toepassing gedefinieerde helper waarmee de browser wordt omgeleid. Geen van beide bewerkingen wisselt een autorisatiecode in.

De callback wisselt een code voor tokens uit

Na een succesvolle autorisatiereactie leidt Microsoft Entra ID de browser om naar de callback-URI van de toepassing met een autorisatiecode. Het volgende fragment richt zich op verzilvering, nadat de callback state heeft gevalideerd, foutresponsen heeft afgehandeld en authCode heeft geëxtraheerd. De volledige callback-implementatie wordt niet weergegeven.

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 verbindt de ontvangen code met de callback-URI en het aangevraagde bereik. De omleidings-URI moet overeenkomen met de URI die wordt gebruikt in de autorisatieaanvraag en de app-registratie. De vertrouwde client authenticeert de toepassing bij het inwisselen van de code op het token-eindpunt.

acquireToken retourneert een toekomst en .get() wacht op het resultaat in dit voorbeeld. Een succesvolle inwisseling resulteert in een IAuthenticationResult; een mislukte omwisseling moet als fout worden afgehandeld. Autorisatiecodes zijn van korte duur en slechts één keer te gebruiken, geen herbruikbare inloggegevens voor latere API-aanroepen.

De toepassing koppelt het resultaat aan een sessie

Het volgende fragment illustreert de grens tussen het ontvangen van tokens en het behandelen van een sessie als geverifieerd. context Hier ziet u een toepassingsgedefinieerde IdentityContextData instantie.

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

De eerste aanroep maakt de claims van het ID-token beschikbaar voor de noncevalidatie van de toepassing. De door de toepassing gedefinieerde validateNonce helper vergelijkt de geretourneerde nonce met de waarde die wordt bewaard voor de oorspronkelijke aanvraag en stopt de verwerking als de validatie mislukt. De laatste aanroep registreert het verificatieresultaat en de geserialiseerde tokencache in de toepassingscontext, die de omringende code aan de sessie koppelt.

Deze helpers vervangen de bredere beveiligingsverantwoordelijkheden van de toepassing niet. Een volledige implementatie heeft ook de juiste reactieverwerking nodig, beveiligde sessie- en tokencacheopslag, de juiste foutafhandeling en autorisatie voor beveiligde bewerkingen.

De stroom verbinden

De browser loodst de gebruiker door het aanmeldproces en geeft een autorisatiecode terug. De server wisselt die code in met MSAL4J, verwerkt het resultaat en onderhoudt de sessie van de toepassing. Latere Microsoft Graph-aanroepen gebruiken een toegangstoken, niet de autorisatiecode of het id-token.

Zie MSAL4J-generator voor autorisatiecode-URL's en Tokens verkrijgen met autorisatiecodes voor meer informatie over de bibliotheek-API's.