Condividi tramite

Single Sign-On con MSAL.js

  • Articolo

Single Sign-On (SSO) offre un'esperienza più semplice riducendo il numero di richieste di credenziali rivolte agli utenti. Gli utenti immettono le credenziali una sola volta e la sessione stabilita può essere riutilizzata da altre applicazioni nello stesso dispositivo senza richiedere ulteriore conferma.

Microsoft Entra ID abilita l'accesso SSO impostando un cookie di sessione quando un utente esegue l'autenticazione per la prima volta. MSAL.js memorizza nella cache anche i token ID e i token di accesso dell'utente nella risorsa di archiviazione del browser per ogni dominio dell'applicazione. I due meccanismi, il cookie di sessione di Microsoft Entra e la cache di Microsoft Authentication Library (MSAL), sono indipendenti tra loro, ma interagiscono per fornire il comportamento SSO.

Single Sign-On tra le schede del browser per la stessa app

Quando un utente ha un'applicazione aperta in diverse schede e accede a una di esse, può essere eseguito l'accesso alla stessa app aperta in altre schede senza che vengano fatte altre richieste all'utente. A tale scopo, nell'oggetto di configurazione MSAL.js è necessario impostare cacheLocation su localStorage come illustrato nell'esempio seguente:

const config = {
  auth: {
    clientId: "1111-2222-3333-4444-55555555",
  },
  cache: {
    cacheLocation: "localStorage",
  },
};

const msalInstance = new msal.PublicClientApplication(config);

In questo caso le istanze dell'applicazione di schede del browser diverse usano la stessa cache MSAL condividendo così lo stato di autenticazione tra di loro. È possibile anche usare gli eventi MSAL per aggiornare le istanze dell'applicazione quando un utente accede da un'altra scheda o finestra del browser. Per altre informazioni, vedere: Sincronizzazione dello stato connesso tra schede e finestre

SSO tra app diverse

Quando un utente esegue l'autenticazione, un cookie di sessione viene impostato nel dominio Microsoft Entra del browser. MSAL.js si basa su questo cookie di sessione per fornire l'accesso SSO all'utente tra applicazioni diverse. In particolare MSAL.js offre il metodo ssoSilent per far accedere l'utente e ottenere i token senza alcuna interazione. Tuttavia, se l'utente ha più account utente in una sessione con Microsoft Entra ID, viene richiesto di selezionare l'account con cui accedere. Di conseguenza esistono due modi per ottenere l'accesso SSO usando il metodo ssoSilent.

Con hint utente

Per migliorare le prestazioni e assicurarsi che il server di autorizzazione cerchi la sessione dell'account corretta, è possibile passare una delle opzioni seguenti nell'oggetto richiesta del metodo ssoSilent per ottenere il token in modo invisibile all'utente.

È consigliabile usare l'attestazione login_hint di token ID facoltativa fornita a ssoSilent così come loginHint è l'hint dell'account più affidabile per le richieste invisibile all'utente e interattive.

Uso di un hint di accesso

L'attestazione login_hint facoltativa fornisce un suggerimento per Microsoft Entra ID sull'account utente che tenta di accedere. Per ignorare la richiesta di selezione dell'account visualizzata in genere durante le richieste di autenticazione interattive, specificare loginHint come illustrato:

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
    }
}

In questo esempio loginHint contiene il messaggio e-mail o il nome di accesso UPN dell'utente, che viene usato come hint durante le richieste di token interattive. L'hint può essere passato tra le applicazioni per facilitare l'accesso SSO invisibile all'utente, in cui l'applicazione A può accedere a un utente, leggere loginHint, quindi inviare l'attestazione e il contesto del tenant corrente all'applicazione B. Microsoft Entra ID tenterà di pre-compilare il modulo di accesso o ignorare la richiesta di selezione dell'account e procedere direttamente con il processo di autenticazione per l'utente specificato.

Se le informazioni nell'attestazione login_hint non corrispondono ad alcun utente esistente, queste vengono reindirizzate affinché seguano l'esperienza di accesso standard, inclusa la selezione dell'account.

Uso di un ID sessione

Per usare un ID sessione, aggiungere sid come attestazione facoltativa ai token ID dell'app. L'attestazione sid consente a un'applicazione di identificare la sessione Microsoft Entra di un utente indipendentemente dal nome dell'account o dal nome utente. Per informazioni su come aggiungere attestazioni facoltative come sid, vedere Fornire attestazioni facoltative all'app. Usare l'ID sessione (SID) nelle richieste di autenticazione invisibili eseguite con ssoSilent in 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
    }
}

Uso di un oggetto account

Se si conoscono le informazioni sull'account utente, si può anche recuperare l'account utente usando i metodi getAccountByUsername() o 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
    }
}

Senza hint utente

È possibile tentare di usare il metodo ssoSilent senza passare alcun account sid oggetto o login_hint come illustrato nel codice seguente:

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
    }
}

Tuttavia, è possibile che si presentino errori di accesso invisibili all'utente se l'applicazione ha più utenti in una singola sessione del browser o se l'utente ha più account per tale singola sessione del browser. Se sono disponibili più account, è possibile che venga visualizzato l'errore seguente:

InteractionRequiredAuthError: interaction_required: AADSTS16000: Either multiple user identities are available for the current request or selected account is not supported for the scenario.

L'errore indica che il server non è riuscito a determinare l'account di cui eseguire l'accesso e richiederà uno dei parametri dell'esempio precedente (account, login_hint, sid) o un accesso interattivo per scegliere l'account.

Considerazioni sull'uso di ssoSilent

URI di reindirizzamento (URL di risposta)

Per prestazioni migliori e per evitare problemi, impostare redirectUri su una pagina vuota o un'altra pagina che non usa MSAL.

  • .Se gli utenti dell'applicazione visualizzano solo i metodi popup e invisibili all'utente, impostare redirectUri sull'oggetto di configurazione PublicClientApplication.
  • Se l'applicazione usa anche metodi di reindirizzamento, impostare redirectUri in base a ogni richiesta.

Cookie di terze parti

ssoSilent tenta di aprire un iframe nascosto e riutilizzare una sessione esistente con Microsoft Entra ID. Ciò non funzionerà nei browser che bloccano cookie di terze parti, ad esempio Safari, e verrà generato un errore di interazione:

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

Per risolvere l'errore, l'utente deve creare una richiesta di autenticazione interattiva usando loginPopup() o loginRedirect(). In alcuni casi il valore si prompt none può essere usato insieme a un metodo interattivo di MSAL.js per ottenere l'accesso SSO. Per altre informazioni, vedere Richieste interattive con prompt=none. Se si dispone già delle informazioni di accesso dell'utente, è possibile passare i parametri facoltativi loginHint o sid per far accedere un account specifico.

Negazione dell'accesso SSO con prompt=login

Se si preferisce Microsoft Entra ID per richiedere all'utente di immettere le credenziali anche se è presente una sessione attiva con il server di autorizzazione, si può usare il parametro prompt di accesso nelle richieste con MSAL.js. Per altre informazioni, vedere Comportamento del prompt MSAL.js.

Condivisione dello stato di autenticazione tra ADAL.js e MSAL.js

MSAL.js presenta parità delle funzionalità con ADAL.js per gli scenari di autenticazione di Microsoft Entra. Per semplificare la migrazione da ADAL.js a MSAL.js facile e condividere lo stato di autenticazione tra le app, la libreria legge il token ID che rappresenta la sessione dell'utente nella cache ADAL.js. Per sfruttare questi vantaggi durante la migrazione da ADAL.js, è necessario assicurarsi che le librerie usino localStorage per la memorizzazione nella cache dei token. Impostare cacheLocation su localStorage in entrambe le configurazioni MSAL.js e ADAL.js in fase di inizializzazione come indicato di seguito:


// 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);

Passaggi successivi

Per altre informazioni sul Single Sign-On, vedere: