Suivre le processus de connexion d’une application web Java

Ce didacticiel suit une requête de connexion à l’aide d’un exemple de code de servlet Java. Il explique comment le navigateur, Microsoft Entra ID, MSAL4J et les helpers de session de l'application interagissent.

Identifier les helpers définis par l’application

MSAL4J fournit les API d’acquisition de jetons. L’application fournit le code environnant qui coordonne les redirections du navigateur, le traitement de rappel et les sessions. Les fragments utilisent ces aides illustratives :

Ces noms et leurs méthodes utilitaires sont définis par l’application ; il ne s’agit pas d’API MSAL4J. Leurs rôles sont expliqués dans la procédure pas à pas, mais leurs implémentations ne sont pas incluses.

Une URL d’autorisation démarre l’interaction du navigateur

Le premier fragment montre comment l’application crée une URL d’autorisation et redirige le navigateur. L’utilitaire fournit un client confidentiel configuré. L’application a également généré de nouvelles valeurs nonce et state, imprévisibles, pour cette requête de connexion et les a conservées pour les comparer ultérieurement.

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 décrit l’URI de rappel, l’étendue demandée et les options de protocole. Collections.singleton est approprié ici, car Config.SCOPES contient une seule étendue, plutôt qu’une liste séparée par un espace de plusieurs étendues. MSAL ajoute par défaut les étendues standard OpenID Connect openid, profile et offline_access.

Avec MSAL4J 1.9.1, ResponseMode.QUERY place les paramètres de réponse d’autorisation dans la chaîne de requête du rappel. Prompt.SELECT_ACCOUNT demande de sélectionner un compte. state permet de mettre en corrélation la réponse avec la demande de connexion, tout en nonce liant le jeton d’ID à cette demande.

getAuthorizationRequestUrl construit l’URL ; redirectUser est l’assistance définie par l’application qui redirige le navigateur. Aucune opération n’échange un code d’autorisation.

La fonction de rappel échange un code contre des jetons

Après une réponse d'autorisation réussie, Microsoft Entra ID redirige le navigateur vers l'URI de rappel de l'application avec un code d'autorisation. Le fragment suivant porte sur l’échange, une fois que le rappel a validé state, géré les réponses d’erreur et extrait authCode. Il n’affiche pas l’intégralité de l’implémentation de la fonction de rappel.

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 connecte le code reçu à l’URI de rappel et à l’étendue demandée. L’URI de redirection doit correspondre à celui utilisé dans la demande d’autorisation et l’inscription de l’application. Le client confidentiel authentifie l’application lors de l’échange du code au niveau du point de terminaison du jeton.

acquireToken renvoie un future, et .get() attend son résultat dans cet exemple. Une rédemption réussie produit un IAuthenticationResult ; un échange ayant échoué doit être traité comme une erreur. Les codes d’autorisation sont de courte durée et d’utilisation unique, et non réutilisables pour les appels d’API ultérieurs.

L’application associe le résultat à une session

Le fragment suivant illustre la limite entre la réception de jetons et le traitement d’une session comme authentifiée. Ici, context est une instance IdentityContextData définie par l’application.

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

Le premier appel rend les déclarations du jeton d’identité disponibles pour la validation du nonce de l’application. La fonction utilitaire validateNonce, définie par l’application, compare la valeur nonce renvoyée à la valeur conservée pour la requête d’origine et interrompt le traitement en cas d’échec de la validation. L’appel final enregistre le résultat d’authentification et le cache de jeton sérialisé dans le contexte de l’application, que le code environnant associe à la session.

Ces assistances ne remplacent pas les responsabilités de sécurité plus larges de l’application. Une implémentation complète nécessite également un traitement de réponse correct, un stockage de session sécurisé et de cache de jetons, une gestion des erreurs appropriée et une autorisation pour les opérations protégées.

Connectez le flux

Le navigateur guide l’utilisateur tout au long du processus de connexion et renvoie un code d’autorisation. Le serveur échange ce code avec MSAL4J, traite le résultat et gère la session de l’application. Par la suite, les appels Microsoft Graph utilisent un jeton d’accès, et non le code d’autorisation ou le jeton d’ID.

Pour plus d’informations sur les API de bibliothèque, consultez le générateur d’URL de code d’autorisation MSAL4J et acquérir des jetons avec des codes d’autorisation.