Comprendre la connexion avec MSAL4J
MSAL4J connecte la configuration de l’application aux API d’authentification et d’acquisition de jetons Plateforme d'identités Microsoft. Cette unité explique un exemple de construction du client et le rôle de la bibliothèque dans le flux de connexion d’une application web.
Bibliothèque d’authentification Microsoft pour Java
Le Bibliothèque d’authentification Microsoft pour Java (MSAL4J) permet aux applications de s’authentifier avec Microsoft identités et d’obtenir des jetons pour les API protégées. Il prend en charge les scénarios impliquant des comptes Microsoft Entra ID, des comptes de Microsoft personnels et Azure AD B2C, à l’aide d’OAuth 2.0 et OpenID Connect.
Note
Les clients AD B2C existants Azure peuvent continuer à utiliser le service. Il n’a pas été disponible pour l’achat par de nouveaux clients depuis le 1er mai 2025, et le support continue jusqu’à au moins mai 2030. Azure AD B2C P2 a été abandonné pour tous les clients le 15 mars 2026 ; la prise en charge continue du service ne couvre pas les fonctionnalités retirées propres à P2.
Pour les nouveaux projets d’identité client, utilisez ID externe Microsoft Entra. Le scénario de ce module concerne un tenant de collaborateurs Microsoft Entra, et non un tenant Azure AD B2C ni un tenant externe External ID. Pour plus d’informations, consultez la FAQ relative à la fin de commercialisation d’Azure AD B2C.
MSAL4J prend en charge plusieurs types d’applications, notamment les applications web, les services en arrière-plan, les applications en ligne de commande et les applications de bureau. Le type de client et le flux d’acquisition de jetons appropriés dépendent de l’environnement de l’application.
Un client confidentiel représente l’application serveur
MSAL distingue les clients publics, qui ne peuvent pas conserver de manière fiable les informations d’identification de l’application confidentielles, des clients confidentiels, qui peuvent s’authentifier à l’aide d’informations d’identification conservées en toute sécurité. Une application web Java côté serveur est un client confidentiel.
Le fragment d'exemple suivant construit ce client. Les noms en majuscules sont des espaces réservés de configuration, et non de véritables identifiants ni des secrets. Les importations, le code d’application environnant et la gestion des exceptions ne sont pas affichés.
IClientCredential credential = ClientCredentialFactory.createFromSecret(CLIENT_SECRET);
ConfidentialClientApplication app = ConfidentialClientApplication
.builder(CLIENT_ID, credential)
.authority(AUTHORITY)
.build();
Le fragment connecte trois entrées :
| Input | Sens |
|---|---|
CLIENT_ID |
Identifiant de l’application issu de l’enregistrement. |
CLIENT_SECRET |
Espace réservé pour le matériel secret fourni au serveur. Cela illustre une fabrique d’informations d’identification, et non une demande de création ou d’incorporation d’un secret. |
AUTHORITY |
URL du fournisseur d’identité et l'audience de connexion. Dans le scénario à locataire unique, il identifie le locataire Microsoft Entra sélectionné. |
ClientCredentialFactory crée un objet d’informations d’identification et le générateur associe ces informations d’identification à l’ID client et à l’autorité de l’application. L’appel à build() construit le client MSAL ; il n’authentifie pas un utilisateur et ne redirige le navigateur vers aucune page.
Rôle de MSAL dans le flux de code d’autorisation
Un client confidentiel authentifie l’application, tandis que l’interaction du navigateur authentifie l’utilisateur. L’application coordonne ces parties du flux :
| Phase | MSAL API | Responsabilité de l’application |
|---|---|---|
| Démarrer la connexion du navigateur | getAuthorizationRequestUrl |
Créez une demande d’autorisation et redirigez le navigateur vers celui-ci. |
| Utiliser un code d’autorisation |
acquireToken avec AuthorizationCodeParameters |
Traitez le rappel, validez la réponse et échangez le code reçu pour les jetons. |
| Obtenir un jeton pour un appel d’API ultérieur |
acquireTokenSilently avec SilentParameters |
Fournissez le compte et le contexte de cache de jeton approprié et gérez les cas nécessitant une interaction utilisateur. |
Pour cette application web, le rappel reçoit un code d’autorisation, et non le jeton d’accès Microsoft Graph. L’échange du code s’effectue via une requête de serveur à serveur au point de terminaison du jeton.
Interpréter le résultat de l’authentification
L’échange de code réussi retourne un IAuthenticationResult. Dans ce scénario OpenID Connect, le résultat fournit un jeton d’ID pour l’application et un jeton d’accès pour l’API demandée. Il fournit également des informations utilisées pour gérer la durée de vie du compte et du jeton.
Le jeton d’ID contient des revendications d’identité ; le jeton d’accès active une requête à son API prévue. Un jeton d'ID n'est pas un substitut à un jeton d'accès Microsoft Graph. MSAL4J acquiert des jetons, mais l’application ou un SDK spécifique à l’API effectue l’appel d’API métier suivant.
L’unité suivante suit ces responsabilités par le biais du code servlet annoté. La vue d’ensemble de MSAL fournit un contexte supplémentaire sur les scénarios pris en charge et la gestion des jetons.