Compartilhar via

FAQ sobre a descontinuação da autenticação de aplicações aninhadas e tokens legados do Outlook

  • Artigo

Os tokens de identidade de utilizador do Exchange e os tokens de chamada de retorno foram preteridos e serão desativados a partir de fevereiro de 2025. Recomendamos que mova os suplementos do Outlook que utilizam tokens do Exchange legados para a autenticação de aplicações aninhadas.

FAQ Gerais

O que é a autenticação de aplicações aninhadas (NAA)?

A autenticação de aplicações aninhadas permite o início de sessão único (SSO) para aplicações aninhadas dentro de aplicações suportadas da Microsoft, como o Outlook. Em comparação com os modelos de autenticação de confiança total existentes e o fluxo em nome de, o NAA proporciona uma melhor segurança e maior flexibilidade na arquitetura de aplicações, permitindo a criação de aplicações avançadas e orientadas pelo cliente. Para obter mais informações, consulte Ativar o SSO num Suplemento do Office através da autenticação de aplicações aninhadas.

Qual é a linha do tempo para encerrar tokens legados do Exchange Online?

A Microsoft começa a desativar os tokens legados do Exchange online em fevereiro de 2025. A partir de agora e até fevereiro de 2025, os inquilinos existentes e novos não serão afetados. Forneceremos ferramentas para os administradores reativarem os tokens do Exchange para inquilinos e suplementos se esses suplementos ainda não forem migrados para o NAA. Consulte Posso ativar novamente os tokens legados? para obter mais informações.

Data Tokens legados status
Fevereiro de 2025 Tokens legados desativados para todos os inquilinos. Os administradores podem reativar tokens legados através do PowerShell.
Junho de 2025 Tokens legados desativados para todos os inquilinos. Os administradores já não podem reativar tokens legados através do PowerShell e devem contactar a Microsoft para qualquer exceção.
Outubro de 2025 Tokens legados desativados para todos os inquilinos. As exceções já não são permitidas.

Quando é que o NAA está geralmente disponível para o meu canal?

A data de disponibilidade geral (GA) para NAA depende do canal que está a utilizar.

Data Disponibilidade Geral (GA) do NAA
Outubro de 2024 NAA é GA no Canal Atual.
Nov 2024 O NAA será ga no Canal Empresarial Mensal.
Janeiro de 2025 A NAA estará disponível no Canal Semi-Annual.
Junho de 2025 A NAA estará disponível em Semi-Annual Canal Alargado.

Perguntas de administrador do Microsoft 365

Posso ativar novamente os tokens legados?

Até meados de novembro de 2024, iremos implementar novas ferramentas através do PowerShell para administradores do Microsoft 365 para ativar ou desativar tokens do Exchange legados no seu inquilino. Se precisar de reativar tokens legados do Exchange, pode utilizar os cmdlets do PowerShell para o fazer. As ferramentas também comunicarão se algum suplemento está a utilizar tokens legados nos últimos 28 dias. Em junho de 2025, os tokens de Exchange Online legados serão desativados e não poderá voltar a ativá-los sem uma exceção específica concedida pela Microsoft. Em outubro de 2025, não será possível ativar tokens de Exchange Online legados e serão desativados para todos os inquilinos. Iremos atualizar estas FAQ com informações adicionais assim que a ferramenta estiver disponível em todos os inquilinos.

Os fornecedores de software independant (ISVs) estão a atualizar os respetivos suplementos para utilizar tokens entra ID e âmbitos do Microsoft Graph. Quando o suplemento pede um token de acesso, tem de ter o consentimento do administrador ou do utilizador. Se o administrador consentir, todos os utilizadores no inquilino podem utilizar o suplemento para os âmbitos necessários para o suplemento. Caso contrário, será pedido consentimento a cada utilizador final, se o consentimento do utilizador estiver ativado. A conclusão do consentimento do administrador proporciona uma melhor experiência, uma vez que os utilizadores não são solicitados.

Uma opção de consentimento é que o ISV lhe fornece um URI de consentimento do administrador.

  1. O programador do suplemento fornece um URI de consentimento do administrador. Se isto não estiver na documentação que fornecem, terá de contactá-los para obter mais informações.
  2. O administrador navega para o URI de consentimento do administrador.
  3. É pedido ao administrador para iniciar sessão e dar consentimento a uma lista de âmbitos de que o suplemento necessita.
  4. Depois de concluído, o browser redireciona para uma página Web a partir do ISV, que deverá mostrar que o consentimento foi bem-sucedido.

Como alternativa, o ISV pode fornecer um manifesto de aplicação atualizado que pedirá o consentimento do administrador como parte da implementação central. Neste cenário, quando implementar o manifesto da aplicação atualizado, ser-lhe-á pedido para dar consentimento antes de a implementação poder ser concluída. Não é necessário um URI de consentimento do administrador.

Por fim, se o suplemento for publicado na loja do Microsoft 365, a atualização será implementada automaticamente e será pedido ao administrador que consoante os âmbitos. Se o administrador não consentir, os utilizadores não poderão utilizar o suplemento atualizado.

Certifique-se de que não desativa funcionalidades ou revoga as permissões necessárias para o suplemento. Por exemplo, veja Modificar as propriedades da política de caixa de correio. O suplemento utiliza permissões delegadas e, por conseguinte, tem acesso aos mesmos recursos que o utilizador com sessão iniciada. No entanto, se uma política ou definição bloquear o utilizador de um determinado recurso ou ação, o suplemento também será bloqueado.

Como fazer implementar atualizações de suplementos a partir de um ISV?

Se tiver um suplemento que utiliza tokens legados do Exchange, deve contactar o ISV para obter informações sobre os respetivos linha do tempo para migrar o suplemento para utilizar o NAA. Assim que o ISV migrar o respetivo suplemento, provavelmente fornecerá um URL de consentimento do administrador. Para obter mais informações, veja Como funciona o fluxo de consentimento do administrador? .

O ISV também pode fornecer-lhe um manifesto de aplicação atualizado para implementar através da implementação centralizada. Durante a implementação centralizada, isto pode pedir-lhe para dar consentimento a todos os âmbitos do Microsoft Graph necessários para o suplemento. Neste cenário, não terá de utilizar um URI de consentimento do administrador.

Se o suplemento for implementado a partir do Microsoft AppSource, o mais provável é que lhe seja pedido para dar consentimento aos âmbitos do Microsoft Graph quando o ISV lançar atualizações para o suplemento. Até dar consentimento, os utilizadores no inquilino não poderão utilizar a nova versão do suplemento com NAA.

Que suplementos na minha organização são afetados?

Iremos fornecer ferramentas para administradores que reportam o ID da aplicação de qualquer suplemento que tenha utilizado tokens legados do Exchange Online nos últimos 28 dias. Iremos fornecer mais informações nestas FAQ quando as ferramentas estiverem prontas. Para obter mais informações, consulte Posso ativar novamente os tokens legados?.

Os suplementos podem utilizar os tokens legados do Exchange para obter recursos do Exchange através das APIs REST do EWS ou do Outlook. Por vezes, um suplemento requer recursos do Exchange para alguns casos de utilização e não para outros, dificultando a deteção de se o suplemento necessita de uma atualização. Recomendamos que contacte os programadores e proprietários dos suplementos para lhes perguntar se o respetivo código de suplemento faz referência às seguintes APIs.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Se depender de um ISV para o seu suplemento, recomendamos que o contacte o mais rapidamente possível para confirmar que tem um plano e um linha do tempo para sair dos tokens do Exchange legados. Os programadores de ISV devem contactar diretamente os respetivos contactos da Microsoft com perguntas para garantir que estão prontos para o fim dos tokens legados do Exchange. Se depender de um programador na sua organização, estes devem rever estas FAQ e o artigo Ativar o SSO num Suplemento do Office através da autenticação de aplicações aninhadas. Quaisquer questões devem ser levantadas no site de problemas do GitHub OfficeDev/office-js.

Assim que o administrador ou um utilizador consentir, este será listado no centro de administração do Microsoft Entra. Pode encontrar registos de aplicações com os seguintes passos.

  1. Saiba mais em https://entra.microsoft.com/#home.
  2. No painel de navegação esquerdo, selecione Aplicações>Registros de aplicativo.
  3. Na página Registros de aplicativo, selecione Todas as aplicações.
  4. Agora, pode procurar qualquer registo de aplicação por nome ou ID.

FAQ sobre a migração de suplementos do Outlook

Porque é que a Microsoft está a fazer com que os suplementos do Outlook sejam migrados?

Mudar para o Microsoft Graph com tokens de Entra ID é uma grande melhoria na segurança dos clientes do Outlook e do Exchange. O Entra ID (anteriormente Azure Active Directory) é um serviço líder de gestão de identidades e acessos baseado na cloud. Os clientes podem tirar partido de funcionalidades de confiança zero, tais como acesso condicional, requisitos de MFA, monitorização contínua de tokens, heurística de segurança em tempo real e muito mais que não estão disponíveis com tokens do Exchange legados. Os clientes armazenam dados empresariais importantes armazenados no Exchange, pelo que é vital garantir que estes dados estão protegidos. Migrar todo o ecossistema do Outlook para utilizar tokens de Entra ID com o Microsoft Graph melhora significativamente a segurança dos dados dos clientes.

O meu suplemento do Outlook tem de ser migrado para o NAA?

Não. Os suplementos do Outlook não têm de utilizar NAA, embora o NAA ofereça a melhor experiência de autenticação para os utilizadores e a melhor postura de segurança para as organizações. Se os suplementos não estiverem a utilizar tokens do Exchange legados, não serão afetados pela descontinuação dos tokens do Exchange. Os suplementos que utilizam MSAL.js ou outros métodos SSO que dependem do Entra ID continuarão a funcionar.

Como fazer saber se o meu suplemento do Outlook depende de tokens legados?

Iremos fornecer ferramentas para administradores que reportam o ID da aplicação de qualquer suplemento que tenha utilizado tokens legados do Exchange Online nos últimos 28 dias. Iremos fornecer mais informações quando as ferramentas estiverem prontas nestas FAQ. Consulte Posso ativar novamente os tokens legados? para obter mais informações.

Para saber se o seu suplemento utiliza tokens de identidade de utilizador do Exchange legados e tokens de chamada de retorno, pesquise no código chamadas para as seguintes APIs.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Se o suplemento chamar qualquer uma destas APIs, deve adotar o NAA e migrar para utilizar tokens de Entra ID para aceder ao Microsoft Graph.

Que suplementos do Outlook estão no âmbito?

Muitos dos principais suplementos estão no âmbito. Se o seu suplemento estiver a utilizar o EWS ou o Outlook REST para aceder a recursos Exchange Online, é quase certo que precisa de migrar dos tokens do Outlook legados para o NAA. Se o seu suplemento for apenas para o Exchange no local (por exemplo, Exchange 2019), não será afetado por esta alteração.

O que acontecerá aos meus suplementos do Outlook se não migrar para o NAA?

Se não migrar os seus suplementos do Outlook para o NAA, estes deixarão de funcionar conforme esperado no Exchange Online. Quando os tokens do Exchange estão desativados, Exchange Online bloqueará a emissão de tokens legados. Qualquer suplemento que utilize tokens legados não poderá aceder aos recursos online do Exchange.

Se o suplemento só funcionar no local ou se o suplemento estiver num caminho de preterição, poderá não ter de atualizar. No entanto, a maioria dos suplementos que acedem aos recursos do Exchange através do EWS ou do Rest do Outlook tem de migrar para continuar a funcionar conforme esperado.

Como fazer migrar os meus suplementos do Outlook para o NAA?

Para suportar o NAA no seu suplemento do Outlook, veja a seguinte documentação e exemplo.

Como fazer acompanhar as orientações mais recentes?

Iremos atualizar estas FAQ à medida que estiverem disponíveis novas informações. Vamos partilhar orientações adicionais no futuro na chamada da comunidade dos Suplementos do Office e no blogue para programadores do M365. Por fim, pode fazer perguntas sobre o NAA e a preterição de tokens de Exchange Online legado no site de problemas do GitHub officeDev/office-js. Coloque "NAA" no título para que possamos agrupar e priorizar problemas.

Se submeter um problema, inclua as seguintes informações.

  • Versão do cliente do Outlook.
  • Audiência do canal de lançamento do Outlook (para o cliente).
  • Captura de ecrã do problema.
  • A plataforma onde ocorre o problema (Windows, Outlook (novo), Mac, iOS, Android).
  • ID da sessão onde o problema é encontrado.
  • Tipo de conta a ser utilizada.
  • Versão do msal-browser.
  • Registos do msal-browser.

Perguntas de resolução de problemas para programadores

O NAA não está a fornecer o SSO e continua a pedir aos utilizadores para iniciarem sessão

Isto pode ocorrer quando o NAA não está disponível no cliente do Outlook. Se estiver no Windows, marcar que está a utilizar o Canal Beta ou o Canal Atual (Pré-visualização). Tem de aderir ao Programa Insider do Microsoft 365 para mudar para estes canais. Uma boa forma de marcar se o NAA estiver disponível é marcar o conjunto de requisitos com o seguinte fragmento de código. Office.context.requirements.isSetSupported("NestedAppAuth")

Como fazer obter mais informações de depuração da MSAL e da NAA?

Utilize o seguinte código para ativar as informações de depuração no msalConfig quando inicializar a aplicação cliente pública analítica. Esta ação irá registar detalhes adicionais na consola.

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

Conteúdo relacionado