Início de sessão único com MSAL.js

O único sign-on (SSO) proporciona uma experiência mais perfeita, reduzindo o número de vezes que os seus utilizadores são solicitados para as suas credenciais. Os utilizadores introduzem as suas credenciais uma vez, e a sessão estabelecida pode ser reutilizada por outras aplicações no dispositivo sem mais solicitações.

O Azure Ative Directory (Azure AD) permite o SSO definindo um cookie de sessão quando um utilizador autentica pela primeira vez. MSAL.js permite o uso do cookie de sessão para SSO entre os separadores do navegador abertos para uma ou várias aplicações.

SSO entre separadores de navegador para a mesma app

Quando um utilizador tem a sua aplicação aberta em vários separadores e assina em um deles, pode ser assinada na mesma aplicação aberta nas outras abas sem ser solicitada. Para tal, terá de definir o cacheLocation no MSAL.js objeto de configuração, localStorage conforme mostrado abaixo.

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

const msalInstance = new msal.PublicClientApplication(config);

SSO entre diferentes apps

Quando um utilizador autentica, um cookie de sessão é definido no domínio AZure AD no navegador. MSAL.js conta com este cookie de sessão para fornecer SSO para o utilizador entre diferentes aplicações. MSAL.js também caches os tokens de ID e tokens de acesso do utilizador no armazenamento do navegador por domínio de aplicação.

MSAL.js oferece o ssoSilent método para iniciar sôm no utilizador e obter fichas sem uma interação. No entanto, se o utilizador tiver várias contas de utilizador numa sessão com a Azure AD, então o utilizador é solicitado a escolher uma conta para iniciar sessão. Como tal, existem duas formas de obter o método de utilização do ssoSilent SSO.

Com dica de utilizador

Para melhorar o desempenho e garantir que o servidor de autorização procurará a sessão de conta correta. Pode passar uma das seguintes opções no objeto de pedido do ssoSilent método para obter o símbolo silenciosamente.

  • ID sid de sessão (que pode ser recuperado de idTokenClaims um account objeto)
  • login_hint (que pode ser recuperado da propriedade do nome de utilizador do account objeto ou da upn reclamação no token de ID)
  • account (que pode ser recuperado da utilização de um dos métodos de conta)

Usando um ID de sessão

Para utilizar um ID de sessão, adicione sid como uma reivindicação opcional aos tokens de ID da sua aplicação. A sid alegação permite que uma aplicação identifique a sessão Azure AD de um utilizador independente do seu nome de conta ou nome de utilizador. Para aprender a adicionar reclamações opcionais como sid, consulte Fornecer reclamações opcionais à sua aplicação. Utilize o ID da sessão (SID) em pedidos de autenticação silenciosa com ssoSilent os 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
    }
}

Usando uma dica de login

Para contornar o pedido de seleção de conta normalmente mostrado durante pedidos de autenticação interativa (ou para pedidos silenciosos quando ainda não tenha configurado a sid reclamação opcional), forneça um loginHint. Em aplicações multi-arrendatários, também incluem um domain_hint.

const request = {
  scopes: ["user.read"],
  loginHint: preferred_username,
  extraQueryParameters: { domain_hint: "organizations" },
};

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

Obtenha os valores para loginHint e domain_hint a partir do token de ID do utilizador:

  • loginHint: Utilize o valor de reclamação do símbolo de preferred_username identificação.

  • domain_hint: Utilize o valor de reclamação do símbolo de tid identificação. Exigido nos pedidos feitos por aplicações multi-arrendatários que utilizam a /autoridade comum . Opcional para outras aplicações.

Para obter mais informações sobre a dica de login e sugestão de domínio, consulte a plataforma de identidade da Microsoft e o fluxo de código de autorização OAuth 2.0.

Usando um objeto de conta

Se conhecer as informações da conta de utilizador, também pode recuperar a conta do utilizador utilizando os getAccountByUsername() métodos ou getAccountByHomeId() métodos:

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

Sem insinuação do utilizador

Pode tentar utilizar o ssoSilent método sem passar nenhum account, sid ou login_hint como mostrado no código abaixo:

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

No entanto, existe uma probabilidade de erros de inscrição silenciosa se a aplicação tiver vários utilizadores numa única sessão de navegador ou se o utilizador tiver várias contas para essa sessão de navegador único. Pode ver o seguinte erro no caso de várias contas:

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

O erro indica que o servidor não conseguiu determinar em que conta se iniciará, e exigirá um dos parâmetros acima (account, login_hint, ) sidou um inserção interativo para escolher a conta.

Considerações ao utilizar ssoSilent

Redirecionamento URI (URL de resposta)

Para um melhor desempenho e para ajudar a evitar problemas, deite a página redirectUri em branco ou outra página que não utilize o MSAL.

  • Se os utilizadores da aplicação apenas popup e métodos silenciosos, defina o redirectUri objeto de PublicClientApplication configuração.
  • Se a sua aplicação também utilizar métodos de redirecionamento, desa um redirectUri conjunto de pedidos.

Cookies de terceiros

ssoSilent tenta abrir um iframe oculto e reutilizar uma sessão existente com a Azure AD. Isto não funcionará em navegadores que bloqueiam cookies de terceiros, como o safari, e levará a um erro de interação:

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

Para resolver o erro, o utilizador deve criar um pedido de autenticação interativo utilizando o loginPopup() ou loginRedirect().

Além disso, o objeto de pedido é necessário ao utilizar os métodos silenciosos . Se já tiver as informações de entrada do utilizador, pode passar os parâmetros ou sid os loginHint parâmetros opcionais para iniciar uma conta específica.

SSO em ADAL.js para MSAL.js atualização

MSAL.js traz paridade de funcionalidades com ADAL.js para cenários de autenticação AD Azure. Para tornar a migração de ADAL.js para MSAL.js fácil e para evitar que os seus utilizadores voltem a fazer sessão, a biblioteca lê o sinal de ID que representa a sessão do utilizador em cache ADAL.js e sinais perfeitamente no utilizador em MSAL.js.

Para aproveitar o comportamento do SSO ao atualizar a partir de ADAL.js, terá de garantir que as bibliotecas estão a usar localStorage para caching tokens. Desa esta medida cacheLocationlocalStorage na configuração MSAL.js e ADAL.js na inicialização da seguinte forma:


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

cacheLocation Uma vez configurado, MSAL.js pode ler o estado em cache do utilizador autenticado em ADAL.js e usá-lo para fornecer SSO em MSAL.js.

Passos seguintes

Para obter mais informações sobre sSO, consulte: