Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’authentification unique (SSO) offre une expérience plus transparente en réduisant le nombre de fois où un utilisateur est invité à fournir des informations d’identification. Les utilisateurs entrent leurs informations d’identification une seule fois, et la session établie peut être réutilisée par d’autres applications sur le même appareil sans invite supplémentaire.
Microsoft Entra ID active l’authentification unique en définissant un cookie de session lorsqu’un utilisateur s’authentifie pour la première fois. MSAL.js met également en cache les jetons d’ID et les jetons d’accès de l’utilisateur dans le stockage du navigateur par domaine d’application. Les deux mécanismes, le cookie de session Microsoft Entra et le cache de Microsoft Authentication Library (MSAL), sont indépendants l’un de l’autre, mais fonctionnent ensemble pour offrir une expérience d’authentification unique.
SSO entre les onglets d’un navigateur pour une même application
Lorsqu’un utilisateur dispose d’une application ouverte dans plusieurs onglets et se connecte à l’un d’eux, il peut être connecté à la même application ouverte sur d’autres onglets sans être invité. Pour ce faire, vous devez définir cacheLocation dans l’objet de configuration MSAL.js sur localStorage, comme indiqué dans l’exemple suivant :
const config = {
auth: {
clientId: "1111-2222-3333-4444-55555555",
},
cache: {
cacheLocation: "localStorage",
},
};
const msalInstance = new msal.PublicClientApplication(config);
Dans ce cas, les instances d’application dans différents onglets de navigateur utilisent le même cache MSAL, partageant ainsi l’état d’authentification entre eux. Vous pouvez également utiliser des événements MSAL pour mettre à jour les instances d’application lorsqu’un utilisateur se connecte à partir d’un autre onglet ou fenêtre de navigateur. Pour plus d’informations, consultez : Synchronisation de l’état connecté entre les onglets et les fenêtres
Authentification unique entre différentes applications
Lorsqu’un utilisateur s’authentifie, un cookie de session est défini sur le domaine Microsoft Entra dans le navigateur. MSAL.js s’appuie sur ce cookie de session pour fournir l’authentification unique pour l’utilisateur entre différentes applications. En particulier, MSAL.js propose la méthode ssoSilent pour connecter l’utilisateur et obtenir des jetons sans interaction de l’utilisateur. Toutefois, si l'utilisateur dispose de plusieurs comptes d'utilisateur dans une session avec Microsoft Entra ID, il est alors invité à choisir un compte avec lequel se connecter. Ainsi, il existe deux façons de mettre en œuvre l’authentification unique à l’aide de la méthode ssoSilent.
Avec indice utilisateur
Pour améliorer les performances et vous assurer que le serveur d’autorisation recherche la session de compte appropriée, vous pouvez passer l’une des options suivantes dans l’objet de requête de la ssoSilent méthode pour obtenir le jeton en mode silencieux.
-
login_hint, qui peut être récupéré à partir de la propriété du nom d’utilisateur de l’objetaccountou de la revendicationupndans le jeton d’ID. Si votre application authentifie les utilisateurs avec B2C, consultez : Configurer des flux d’utilisateurs B2C pour émettre un nom d’utilisateur dans des jetons d’ID - ID de session,
sidqui peut être récupéré à partiridTokenClaimsd’unaccountobjet. -
account, qui peut être récupéré en utilisant l’une des méthodes de compte.
Nous vous recommandons d’utiliser la login_hintrevendication facultative du jeton d’ID fournie à ssoSilent sous la forme de loginHint, car il s’agit de l’indice de compte le plus fiable pour les requêtes silencieuses et interactives.
Utilisation d’un indicateur de connexion
La revendication facultative login_hint donne à Microsoft Entra ID une indication sur le compte utilisateur qui tente de se connecter. Pour contourner l’invite de sélection du compte généralement affichée pendant les demandes d’authentification interactives, indiquez ce loginHint qui suit :
const silentRequest = {
scopes: ["User.Read", "Mail.Read"],
loginHint: "user@contoso.com"
};
try {
const loginResponse = await msalInstance.ssoSilent(silentRequest);
} catch (err) {
if (err instanceof InteractionRequiredAuthError) {
const loginResponse = await msalInstance.loginPopup(silentRequest).catch(error => {
// handle error
});
} else {
// handle error
}
}
Dans cet exemple, loginHint contient l’e-mail ou l’UPN de l’utilisateur, qui est utilisé comme indicateur pendant les demandes de jetons interactives. L’indice peut être transmis entre les applications pour faciliter l’authentification unique silencieuse, où l’application A peut connecter un utilisateur, lire loginHint, puis envoyer la revendication et le contexte du locataire actuel à l’application B. Microsoft Entra ID essaiera de préremplir le formulaire de connexion ou d’ignorer l’invite de sélection du compte et de passer directement au processus d’authentification pour l’utilisateur spécifié.
Si les informations contenues dans la login_hint revendication ne correspondent à aucun utilisateur existant, elles sont redirigées pour passer par l’expérience de connexion standard, y compris la sélection de compte.
Utilisation d’un ID de session
Pour utiliser un ID de session, ajoutez sid en tant que revendication facultative aux jetons d’ID de votre application. La sid revendication permet à une application d'identifier la session Microsoft Entra d'un utilisateur indépendamment de son nom de compte ou de son nom d'utilisateur. Pour savoir comment ajouter des revendications facultatives comme sid, consultez Fournir des revendications facultatives à votre application. Utilisez l’ID de session (SID) dans les demandes d’authentification silencieuses que vous effectuez dans ssoSilent MSAL.js.
const request = {
scopes: ["user.read"],
sid: sid,
};
try {
const loginResponse = await msalInstance.ssoSilent(request);
} catch (err) {
if (err instanceof InteractionRequiredAuthError) {
const loginResponse = await msalInstance.loginPopup(request).catch(error => {
// handle error
});
} else {
// handle error
}
}
Utilisation d’un objet de compte
Si vous connaissez les informations du compte d’utilisateur, vous pouvez également récupérer le compte d’utilisateur à l’aide des getAccountByUsername() méthodes suivantes getAccountByHomeId() :
const username = "test@contoso.com";
const myAccount = msalInstance.getAccountByUsername(username);
const request = {
scopes: ["User.Read"],
account: myAccount
};
try {
const loginResponse = await msalInstance.ssoSilent(request);
} catch (err) {
if (err instanceof InteractionRequiredAuthError) {
const loginResponse = await msalInstance.loginPopup(request).catch(error => {
// handle error
});
} else {
// handle error
}
}
Sans indication de l’utilisateur
Vous pouvez essayer d’utiliser la ssoSilent méthode sans passer account, sid ou login_hint comme indiqué dans le code suivant :
const request = {
scopes: ["User.Read"]
};
try {
const loginResponse = await msalInstance.ssoSilent(request);
} catch (err) {
if (err instanceof InteractionRequiredAuthError) {
const loginResponse = await msalInstance.loginPopup(request).catch(error => {
// handle error
});
} else {
// handle error
}
}
Toutefois, il existe une probabilité d’erreurs de connexion silencieuse si l’application comporte plusieurs utilisateurs dans une session de navigateur unique ou si l’utilisateur a plusieurs comptes pour cette session de navigateur unique. L’erreur suivante peut s’afficher si plusieurs comptes sont disponibles :
InteractionRequiredAuthError: interaction_required: AADSTS16000: Either multiple user identities are available for the current request or selected account is not supported for the scenario.
L’erreur indique que le serveur n’a pas pu déterminer quel compte se connecter et nécessite l’un des paramètres de l’exemple précédent (account, login_hint, sid) ou une connexion interactive pour choisir le compte.
Considérations relatives à l’utilisation ssoSilent
URI de redirection (URL de réponse)
Pour améliorer les performances et éviter les problèmes, définissez redirectUri sur une page vide ou sur une autre page qui n’utilise pas MSAL.
- Si l’application utilise uniquement des méthodes contextuelles et silencieuses, définissez
redirectUrisur l’objet de configurationPublicClientApplication. - Si l’application utilise également des méthodes de redirection, définissez la
redirectUrivaleur par requête.
Cookies tiers
ssoSilenttente d’ouvrir un iframe masqué et de réutiliser une session existante avec Microsoft Entra ID. Cela ne fonctionnera pas dans les navigateurs qui bloquent les cookies tiers tels que Safari et entraînent une erreur d’interaction :
InteractionRequiredAuthError: login_required: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD
Pour résoudre l’erreur, l’utilisateur doit créer une demande d’authentification interactive à l’aide du loginPopup() ou loginRedirect(). Dans certains cas, la valeur d’invite none peut être utilisée avec une méthode MSAL.js interactive pour obtenir l’authentification unique. Voir Requêtes interactives avec prompt=none pour en savoir plus. Si vous disposez déjà des informations de connexion de l’utilisateur, vous pouvez transmettre l’un des paramètres facultatifs loginHint ou sid pour connecter un compte spécifique.
Désactivation du SSO avec prompt=login
Si vous préférez que Microsoft Entra ID demande à l’utilisateur de saisir ses informations d’identification malgré une session active avec le serveur d’autorisation, vous pouvez utiliser le paramètre prompt login dans les requêtes avec MSAL.js. Pour en savoir plus, consultez le comportement de l’invite dans MSAL.js.
Partage de l’état d’authentification entre ADAL.js et MSAL.js
MSAL.js apporte la parité des fonctionnalités avec ADAL.js pour les scénarios d’authentification Microsoft Entra. Pour faciliter la migration d’ADAL.js vers MSAL.js et partager l’état d’authentification entre les applications, la bibliothèque lit le jeton d’identité qui représente la session de l’utilisateur dans le cache d’ADAL.js. Pour tirer parti de cette opération lors de la migration à partir de ADAL.js, vous devez vous assurer que les bibliothèques utilisent localStorage pour la mise en cache des jetons. Définissez cacheLocation sur localStorage dans les configurations MSAL.js et ADAL.js lors de l’initialisation, comme suit :
// In ADAL.js
window.config = {
clientId: "1111-2222-3333-4444-55555555",
cacheLocation: "localStorage",
};
var authContext = new AuthenticationContext(config);
// In latest MSAL.js version
const config = {
auth: {
clientId: "1111-2222-3333-4444-55555555",
},
cache: {
cacheLocation: "localStorage",
},
};
const msalInstance = new msal.PublicClientApplication(config);
Étapes suivantes
Pour plus d’informations sur l’authentification unique, consultez :