Partilhar 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 NAA é 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.

Os Suplementos COM são afetados pela preterição de tokens de Exchange Online legados?

É muito improvável que quaisquer suplementos COM sejam afetados pela preterição de tokens de Exchange Online legados. Os suplementos Web do Outlook são afetados principalmente porque podem utilizar Office.js APIs que dependem de tokens do Exchange. Para obter mais informações, vejaComo posso saber se o meu suplemento do Outlook depende de tokens legados. Os tokens do Exchange são utilizados para aceder aos Serviços Web exchange (EWS) ou às APIs REST do Outlook, ambas preteridas. Se suspeitar que um suplemento COM pode ser afetado, pode testá-lo ao utilizá-lo num inquilino com os tokens do Exchange desativados. Para obter mais informações, veja Ativar ou desativar tokens de Exchange Online legados.

Perguntas de administrador do Microsoft 365

Posso voltar a ativar Exchange Online tokens legados?

Sim, existem comandos do PowerShell que pode utilizar para ativar ou desativar tokens legados em qualquer inquilino. Para obter mais informações sobre como ativar ou desativar tokens legados, consulte Ativar ou desativar tokens de Exchange Online legados. Se utilizar os comandos para ativar tokens de Exchange Online legados, estes não serão desativados em fevereiro de 2025. Permanecerão ativadas até junho de 2025 ou até que utilize as ferramentas para desativá-las.

Em junho de 2025, os tokens 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 os tokens legados e estes serão desativados para todos os inquilinos. Iremos atualizar estas FAQ com informações adicionais assim que a ferramenta estiver disponível.

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?

Publicámos uma lista de todos os suplementos do Outlook publicados na Microsoft Store que utilizam tokens legados a partir de outubro de 2024. Para obter mais informações sobre como utilizar a lista e criar um relatório de suplementos do Outlook que estão potencialmente a utilizar tokens legados, consulte Localizar suplementos do Outlook que utilizam tokens de Exchange Online legados. Além disso, estamos a trabalhar nas ferramentas de relatórios para facilitar o controlo de suplementos com tokens legados. Esperamos ter as ferramentas de relatório disponíveis no início de 2025.

Os suplementos podem utilizar os tokens legados 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.

Existe uma lista de editores que atualizaram os respetivos suplementos?

Alguns editores de suplementos do Outlook amplamente utilizados já atualizaram os respetivos suplementos, conforme listado abaixo.

Se o editor tiver atualizado o respetivo manifesto e o suplemento for implementado através da Microsoft Store, ser-lhe-á pedido como administrador para atualizar e implementar as atualizações. Se o publicador tiver atualizado o respetivo manifesto e o suplemento for implementado através da implementação central, terá de implementar o novo manifesto como administrador. Em alguns casos, o publicador pode ter um URI de consentimento do administrador que tem de utilizar para consentir novos âmbitos para o suplemento. Contacte os editores se precisar de mais informações sobre a atualização de um suplemento.

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?

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 sobre programadores

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

Como fazer validar o token de ID ou autenticar o utilizador?

Com os tokens do Exchange, pode validar o token de ID e utilizá-lo para autorizar o utilizador a aceder aos seus próprios recursos. Para obter mais informações, veja Authenticate a user with an identity token for Exchange (Autenticar um utilizador com um token de identidade para o Exchange). No entanto, a MSAL com tokens de Entra ID não utiliza esta abordagem.

Quando pede um token através do MSAL, este devolve sempre três tokens.

Token Objetivo Scopes
Token de ID Fornece informações sobre o utilizador ao cliente (painel de tarefas). profile e openid
Atualizar token Atualiza o ID e os tokens de acesso quando expiram. offline_access
Token de acesso Autentica o utilizador para âmbitos específicos para um recurso, como o Microsoft Graph. Quaisquer âmbitos de recursos, como user.read.

A MSAL devolve sempre estes três tokens. Pede os profileâmbitos , openide offline_access como predefinidos, mesmo que o seu pedido de token não os inclua. Isto garante que o ID e os tokens de atualização são pedidos. No entanto, tem de incluir, pelo menos, um âmbito de recurso, como user.read , por exemplo, para obter um token de acesso. Caso contrário, o pedido pode falhar.

Transmitir o token de ID através de uma chamada de rede para ativar ou autorizar o acesso a um serviço é um anti-padrão de segurança. O token destina-se apenas ao cliente (painel de tarefas) e não há forma de o serviço utilizar de forma fiável o token para se certificar de que o utilizador tem acesso autorizado. Para obter mais informações sobre afirmações de tokens de ID, consulte https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference.

É muito importante que peça sempre um token de acesso aos seus próprios serviços. O token de acesso também inclui as mesmas afirmações de ID, pelo que não precisa de transmitir o token de ID. Em vez disso, crie um âmbito personalizado para o seu serviço. Para obter mais informações sobre as definições de registo de aplicações para os seus próprios serviços, veja API Web protegida: Registo de aplicações. Quando o seu serviço recebe o token de acesso, pode validá-lo e utilizar afirmações de ID a partir do token de acesso.

Conteúdo relacionado