Partager via

Authentification unique avec MSAL.js

  • Article

L’authentification unique offre une expérience plus fluide en réduisant le nombre de fois où vos utilisateurs sont invités à fournir leurs 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 lorsque l’utilisateur s’authentifie pour la première fois. Il met également en cache les jetons d’ID et jetons d’accès de l’utilisateur dans le stockage de navigateur par domaine d’application. Les deux mécanismes, c’est-à-dire le cookie de session Microsoft Entra ID et le cache de la bibliothèque d’authentification Microsoft (MSAL), sont indépendants l’un de l’autre, mais fonctionnent ensemble pour fournir un comportement d’authentification unique.

Authentification unique entre les onglets du navigateur pour la même application

Quand un utilisateur a une application ouverte sous plusieurs onglets et qu’il se connecte sous l’un d’eux, il peut se connecter à la même application ouverte sous les autres onglets sans recevoir d’invite. Pour cela, vous devez définir cacheLocation dans l’objet de configuration MSAL.js sur localStorage, comme illustré 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, et partagent donc l’état d’authentification entre eux. Vous pouvez également utiliser des événements MSAL pour mettre à jour des instances d’application lorsqu’un utilisateur se connecte à partir d’un autre onglet ou une autre 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. Le fichier MSAL.js s’appuie sur ce cookie de session pour assurer l’authentification unique de l’utilisateur entre les différentes applications. En particulier, MSAL.js offre la méthode ssoSilent permettant de connecter l’utilisateur et d’obtenir des jetons sans interaction. Toutefois, si l’utilisateur dispose de plusieurs comptes d’utilisateur auprès de Microsoft Entra ID, il est invité à choisir un compte avec lequel se connecter. Il existe deux façons de réaliser l’authentification unique à l’aide de la méthode ssoSilent.

Avec une indication utilisateur

Pour améliorer les performances et vous assurer que le serveur d’autorisation recherche la bonne session de compte, vous pouvez passer l’une des options suivantes dans l’objet de requête de la méthode pour obtenir le jeton ssoSilent en mode silencieux.

Nous vous recommandons d’utiliser la revendication de jeton d’ID facultative login_hint fournie à ssoSilent en tant que loginHint, car il s’agit de l’indicateur de compte le plus fiable des requêtes silencieuses et interactives.

Utilisation d’un indicateur de connexion

La revendication facultative login_hint fournit un conseil à Microsoft Entra ID concernant le compte d’utilisateur qui tente de se connecter. Pour contourner l’invite de sélection de compte généralement affichée lors des demandes d’authentification interactives, fournissez le loginHint comme illustré :

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’adresse e-mail ou l’UPN de l’utilisateur qui est utilisé comme conseil lors des demandes de jeton interactives. Le conseil peut être transmis entre les applications pour faciliter l’authentification unique en mode silencieux, où l’application A peut connecter un utilisateur, lire le loginHint, puis envoyer la revendication et le contexte de locataire actuel à l’application B. Microsoft Entra ID tentera de pré-remplir le formulaire de connexion ou de contourner l’invite de sélection du compte et de poursuivre directement le processus d’authentification pour l’utilisateur spécifié.

Si les informations contenues dans la revendication login_hint ne correspondent à aucun utilisateur existant, celui-ci est redirigé 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 revendication sid permet à une application d’identifier la session Microsoft Entra d’un utilisateur indépendamment du nom ou du compte de cet utilisateur. Pour découvrir comment ajouter des revendications facultatives telles que sid, consultez Fournir des revendications facultatives à votre application. Utilisez l’ID de session (SID) dans les demandes d’authentification silencieuses que vous créez avec ssoSilent dans 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 méthodes getAccountByUsername() ou 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 utilisateur

Vous pouvez essayer d’utiliser la méthode ssoSilent sans passer de account, de sid ou de 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, des erreurs de connexion silencieuse sont probables si l’application comporte plusieurs utilisateurs dans une seule session de navigateur ou si l’utilisateur a plusieurs comptes pour cette seule session de navigateur. 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 qu’il a besoin de l’un des paramètres mentionnés dans l’exemple précédent (account, login_hint, sid) ou d’une connexion interactive pour choisir le compte.

Considérations lors de l’utilisation de ssoSilent

URI de redirection (URL de réponse)

Pour améliorer les performances et éviter les problèmes, définissez redirectUri sur une page vierge ou une autre page qui n’utilise pas MSAL.

  • Si l’application utilise uniquement des méthodes contextuelles et silencieuses, définissez redirectUri sur l’objet de configuration PublicClientApplication.
  • Si l’application utilise également des méthodes de redirection, définissez redirectUri avec une valeur Sur demande.

Cookies tiers

ssoSilent tente 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 comme Safari et une erreur d’interaction se produira :

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 en utilisant 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. Pour plus d’informations, consultez Requêtes interactives avec prompt=none. Si vous disposez déjà des informations de connexion de l’utilisateur, vous pouvez passer les paramètres facultatifs loginHint ou sid pour se connecter à un compte spécifique.

Négation de l’authentification unique avec prompt=login

Si vous préférez que Microsoft Entra ID invite l’utilisateur à entrer ses informations d’identification en dépit d’une session active avec le serveur d’autorisation, vous pouvez utiliser le paramètre d’invite login dans les requêtes avec MSAL.js. Pour plus d’informations, consultez Comportement d’invite MSAL.js.

Partage de l’état d’authentification entre ADAL.js et MSAL.js

Le fichier MSAL.js fournit une fonctionnalité de parité avec ADAL.js, pour les scénarios d’authentification Microsoft Entra. Pour faciliter la migration de ADAL.js vers MSAL.js et partager l’état d’authentification entre les applications, la bibliothèque lit le jeton d’ID représentant la session de l’utilisateur dans le cache ADAL.js. Pour tirer parti de ce comportement lors de la migration depuis ADAL.js, vous devez vous assurer que les bibliothèques utilisent le paramètre localStorage pour la mise en cache des jetons. Définissez le paramètre cacheLocation sur localStorage dans la configuration des fichiers MSAL.js et ADAL.js lors de l’initialisation, en procédant 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 :