Usando o MSAL em aplicativos em iframe

Por padrão, o MSAL impede redirecionamentos de quadro completo para o endpoint de autenticação do Microsoft Entra ID quando um aplicativo é renderizado em um iframe, o que significa que você não pode usar APIs de redirecionamento para a interação do usuário com o IdP:

  • Essa restrição é imposta porque Microsoft Entra ID se recusará a renderizar qualquer prompt que exija interação do usuário (por exemplo, entrada de credencial, consentimento, logoff etc.) em um iframe lançando o X-FRAME OPTIONS SET TO DENYerro, uma medida tomada para evitar ataques de clickjacking.
  • Em vez disso, você precisará contar com as APIs pop-up da MSAL se a interação do usuário for necessária e/ou APIs silenciosas (ssoSilent(), acquireTokenSilent()) se a interação do usuário puder ser evitada.
  • Da mesma forma, você precisará usar a API logoutPopup() para saídas (:warning: se o aplicativo estiver usando uma versão msal-browser anterior à v2.13, certifique-se de atualizar e substituir a logout() API, pois ele tentará um redirecionamento de quadro completo para Microsoft Entra ID).
  • Ao usar APIs de pop-up, você precisa considerar quaisquer restrições de sandbox impostas pelo aplicativo pai. Em particular, o aplicativo pai precisa definir a flag allow-popups quando o iframe está em sandbox.

Azure AD B2C oferece uma experiência de entrada inserida, que permite renderizar uma interface do usuário de logon personalizada em um iframe. Como a MSAL impede o redirecionamento em iframes por padrão, você precisará definir a opção de configuração allowRedirectInIframe como true para usar esse recurso. Observe que não é recomendável habilitar essa opção para aplicativos em Microsoft Entra ID devido à restrição acima.

Restrições do browser

Como os cookies de sessão do Microsoft Entra em um iframe são considerados cookies de terceiros, determinados navegadores (por exemplo, Safari ou Chrome no modo anônimo) bloqueiam ou excluem esses cookies por padrão. Isso afetará a experiência de login único para aplicativos em iframe, pois eles não terão acesso aos cookies de sessão do IdP (consulte: Login único).

Além disso, quando cookies de terceiros estiverem desabilitados no Chrome, os aplicativos MSAL com iframed não terão acesso ao armazenamento local ou de sessão. MSAL recorrerá ao armazenamento em memória nesse caso.

Logon único

Você pode viabilizar o logon único entre o aplicativo em iframe e o aplicativo pai, tanto com mesma origemquanto com origem cruzadase passar uma dica de conta do aplicativo pai para o aplicativo em iframe.

Aplicativos com a mesma origem

Aplicativos em iframe e aplicativos pai da mesma origem podem ter acesso à mesma instância de cache do MSAL.js e conseguir entrar sem solicitações, desde que ambos os aplicativos configurem o MSAL para usar o armazenamento local como cache. Veja mais: Logon único com MSAL.js

Aplicativos com origem cruzada

Aplicativos iframed e pai com origem cruzada podem usar a API ssoSilent() para obter logon único. Para fazer isso, o aplicativo pai deve passar uma conta, um loginHint (nome de usuário) ou uma ID de sessão (sid) para o aplicativo iframed.

Os aplicativos podem tentar usar ssoSilent sem nenhum dos parâmetros acima. No entanto, lembre-se de que há considerações adicionais ao usar ssoSilent sem fornecer nenhuma informação sobre a sessão do usuário.

Para a comunicação entre origens diferentes entre aplicativos incorporados em iframe e o aplicativo pai, há algumas alternativas que você pode considerar:

  • Você pode adicionar cadeias de caracteres de consulta à origem do iframe no aplicativo pai e recuperá-las posteriormente no filho:
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication({
    auth: {
        clientId: "ENTER_CLIENT_ID",
        authority: "https://login.microsoftonline.com/ENTER_TENANT_ID",
        redirectUri: "/redirect", // set to a blank page for handling auth code response via popups
    },
    cache: {
        cacheLocation: "localStorage", // set your cache location to local storage
    },
});

window.onload = () => {
    
    const urlParams = new URLSearchParams(window.location.search);
    const sid = urlParams.get("sid");

    // attempt SSO
    myMSALObj.ssoSilent({
        sid: sid
    }).then((response) => {
        // do something with response
    }).catch(error => {
        // handle errors
    });
}
  • Você pode usar a API postMessage() no aplicativo pai e escutar eventos de mensagem no filho:
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication({
    auth: {
        clientId: "ENTER_CLIENT_ID",
        authority: "https://login.microsoftonline.com/ENTER_TENANT_ID",
        redirectUri: "/redirect", // set to a blank page for handling auth code response via popups
    },
    cache: {
        cacheLocation: "localStorage", // set your cache location to local storage
    },
});

const parentDomain = "http://localhost:3001";

window.addEventListener("message", (event) => {
    // check the origin of the data
    if (event.origin === parentDomain) {
        const sid = event.data;

        // attempt SSO
        myMSALObj.ssoSilent({
            sid: sid
        }).then((response) => {
            // do something with response
        }).catch(error => {
            // handle errors
        });
    }
});

Tratamento de erros

Você deverá capturar e tratar quaisquer erros se ssoSilent() falhar. Em particular:

  • InteractionRequiredError: será gerado se o consentimento for necessário, o usuário precisará executar a MFA e etc. Esse erro geralmente pode ser tratado simplesmente iniciando uma API interativa.
  • BrowserAuthError: será lançado se nenhuma dica de conta for fornecida ou se ela for inválida, se pop-ups estiverem bloqueados etc. Você precisará inspecionar o errorCode e tratar esses casos adequadamente.
    myMSALObj.ssoSilent({
        sid: sid
    }).then((response) => {
            // do something with response
        }).catch(error => {
            if (error instanceof msal.InteractionRequiredAuthError) {
                myMSALObj.loginPopup()
                    .then((response) => {
                        // do something with response
                    });
            } else if (error instanceof msal.BrowserAuthError) {
                if (error.errorCode === "silent_sso_error") {
                    // e.g. username is null
                }
                if (error.errorCode === "popup_window_error") {
                    // e.g. popups are blocked
                }
            } else {
                console.log(error);
            }
        });

Interação do utilizador

Se você quiser minimizar a comunicação com o IdP que requer interação do usuário ou se você estiver tendo problemas com pop-ups por qualquer motivo, há algumas opções que você pode considerar:

  • Conceda consentimento do administrador. Isso garante que não haja solicitações de consentimento para permissões exigidas pelo aplicativo quando os usuários entrarem pela primeira vez.

  • Pré-autorizar aplicativos cliente. Isso garante que não haja solicitações de consentimento para permissões exigidas pela API Web quando ela é chamada por seus aplicativos cliente.

Logout único

Você pode usar MSAL.js com um URI de logoff de canal frontal para obter efeito de saída única entre aplicativos iframed e pai. Por exemplo, se você quiser que os usuários façam logoff automaticamente dos aplicativos em iframes quando fizerem logoff do aplicativo pai, você deverá habilitar o logoff por canal frontal para os aplicativos em iframes. Para fazer isso, consulte: Como configurar um URI de logout de canal frontal.

  • Last updated on