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

Artigo
02/22/2025

Os tokens de identidade de utilizador do Exchange e os tokens de chamada de retorno foram preteridos e serão desativados a partir de 17 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 a partir de 17 de fevereiro de 2025. A partir de agora e até 17 de fevereiro de 2025, os inquilinos novos e existentes não serão afetados. Fornecemos 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
17 de 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.

O que acontece no dia 17 de fevereiro?

A Microsoft começará a implementar uma alteração a todos os utilizadores em todo o mundo nos inquilinos do Microsoft 365 que desativará a emissão de tokens online do Exchange legados. A implementação demorará várias semanas a ser implementada em todos os utilizadores. Se um suplemento do Outlook pedir um token do Exchange legado e a emissão de tokens estiver desativada, o suplemento receberá um erro. Os suplementos do Outlook que ainda pedem tokens de Exchange Online legados serão interrompidos por esta alteração. Tenha em atenção que, mesmo depois de os tokens legados serem desativados, os tokens legados anteriormente emitidos continuarão a ser válidos até uma hora.

Tenha em atenção que, uma vez que a alteração é aplicada por utilizador e implementada ao longo de várias semanas, poderá ver alguns utilizadores afetados enquanto outros não o são. Se precisar de optar ativamente por não participar nesta alteração, consulte Posso ativar novamente os tokens legados?

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	O NAA está disponível na Semi-Annual Channel build 16.0.17928.20392.
Junho de 2025	A NAA estará disponível em Semi-Annual Canal Alargado.

Como fazer tokens legados processados desativados no Semi-Annual Canal Expandido, que ainda não suporta NAA?

Semi-Annual Canal Alargado só suporta NAA em junho de 2025. Isto significa que, mesmo que os suplementos sejam atualizados para suportar NAA e já não utilizem tokens de Exchange Online legados, não funcionarão neste canal. Se estiver a utilizar Semi-Annual Canal Expandido como administrador, recomendamos o seguinte.

Verifique se o seu inquilino está a utilizar suplementos que necessitem de tokens de Exchange Online legados. Para obter mais informações, veja Localizar suplementos do Outlook que utilizam tokens de Exchange Online legados.
Se tiver implementado suplementos que necessitem de tokens de Exchange Online legados e os suplementos forem necessários para a sua organização, recomendamos que ative os tokens agora para que não sejam desativados após 17 de fevereiro de 2025. Para ativar os tokens, consulte Ativar ou desativar tokens de Exchange Online legados.

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, veja Como 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 o processo de exceção estiver pronto.

Os fornecedores independentes de software (ISVs) estão a atualizar os respetivos suplementos para utilizar tokens de 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. Para uma melhor experiência, uma vez que os utilizadores não são solicitados, conclua o consentimento do administrador.

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

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.
O administrador navega para o URI de consentimento do administrador.
É pedido ao administrador para iniciar sessão e dar consentimento a uma lista de âmbitos de que o suplemento necessita.
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.

Aceda a https://entra.microsoft.com/#home e inicie sessão como administrador no seu inquilino.
No painel de navegação esquerdo, selecione Aplicações Aplicações>Empresariais.
Na página Aplicações empresariais , na secção Gerir , selecione Todas as aplicações.
Selecione o Suplemento. Esta ação irá abrir uma página de descrição geral. Na página de descrição geral, selecione Permissões. Existem duas vistas para permissões; Administração consentimento e Consentimento do utilizador. Selecione Consentimento do utilizador para ver quaisquer consentimentos individuais.

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.

Alguns suplementos estão a ser quebrados. Posso saber se isto se deve ao facto de os tokens do Exchange terem sido desativados?

A partir de 17 de fevereiro de 2025, a Microsoft está a implementar uma atualização para desativar gradualmente tokens de Exchange Online legados para todos os utilizadores. A atualização não desativa os tokens do Exchange no seu inquilino se já tiver ativado tokens de Exchange Online legados.

Se o seu inquilino utilizar um suplemento que ainda depende de tokens do Exchange, o suplemento irá interromper ou perder a funcionalidade. A atualização é implementada por utilizador. Isto significa que um ou mais utilizadores podem ter um suplemento afetado quando os tokens do Exchange estão desativados, mas outros utilizadores ainda teriam um suplemento a funcionar. Se reparar que um suplemento tem problemas e suspeitar que pode ser afetado pelos tokens do Exchange desativados, efetue as seguintes ações.

Verificar a lista de suplementos conhecidos

Publicámos uma lista de suplementos que eram conhecidos por utilizarem tokens do Exchange legados a partir de outubro de 2024. Se um suplemento estiver nesta lista, deve contactar o publicador para ver se existem atualizações disponíveis. Para obter mais informações, veja Localizar suplementos do Outlook que utilizam tokens de Exchange Online legados

Verifique se os tokens estão desativados com Script Lab

Verifique se os tokens de Exchange Online legados estão desativados para um utilizador com o suplemento Script Lab.

Instale Script Lab para o Outlook.
Inicie sessão no Outlook com a conta de utilizador/caixa de correio afetada. Os tokens do Exchange podem estar desativados para um utilizador, mas não para outro até que a implementação esteja concluída.
A partir de um e-mail novo ou existente, abra Script Lab no menu Aplicações e selecione Código no menu Script Lab.
No painel de tarefas Script Lab, selecione o ícone backstage (tem três linhas).
Selecione Exemplos e, em seguida, procure o exemplo Obter um token de identidade de utilizador . Selecione este exemplo para o abrir no editor de código.
Depois de o código do exemplo ser carregado, selecione Executar>Executar neste painel.
Após a execução do código, selecione Obter token.

Se os tokens de Exchange Online legados estiverem ativados, verá um token apresentado na consola como uma cadeia codificada em Base64.

Captura de ecrã de um token apresentado na janela da consola.

Se os tokens de Exchange Online legados estiverem desativados, verá um erro apresentado na consola, conforme mostrado abaixo.

Captura de ecrã de um erro na janela da consola.

Se um suplemento for afetado por tokens do Exchange desativados, pode voltar a ativá-los. Para obter mais informações, consulte Posso voltar a ativar Exchange Online tokens legados?.

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

Testar o suplemento atualizado

Depois de atualizar o suplemento para utilizar o NAA, deve testá-lo em todas as plataformas que suportar, como Mac, dispositivos móveis, Web e Outlook no Windows.

Testar quando os tokens do Exchange estão desativados

Para testar se o suplemento funciona corretamente quando os tokens do Exchange estão desativados, implemente o suplemento num inquilino com tokens desativados e teste-o. Para desativar os tokens, consulte Ativar ou desativar tokens de Exchange Online legados.

Se tiver implementado um padrão em que o seu código utiliza tokens do Exchange, mas depois cair se não estiverem disponíveis, certifique-se de que está a verificar se existem erros corretos. Quando uma chamada para obter um token do Exchange falha, marcar asyncResult.diagnóstico. Se um dos seguintes erros for devolvido, mude para NAA.

GenericTokenError: An internal error has occurred.
InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Testar o código de contingência para Trident+ webview

Se o seu suplemento do Outlook suportar Outlook 2016 ou o Outlook 2019 no Windows, teste se funciona corretamente quando a vista Web Trident+ (Internet Explorer 11) é utilizada. Quando o Webview Trident+ é utilizado, o código tem de reverter para MSAL v2 para abrir uma caixa de diálogo e iniciar sessão no utilizador. Para obter mais informações sobre como implementar o padrão de contingência, veja Suplemento do Outlook com SSO através da autenticação de aplicações aninhadas, incluindo a contingência Explorer Internet.

Testar em Trident+ e WebView2

Outlook 2016 e o Outlook 2019 no Windows utilizam o Trident+ ou o WebView2 com base em várias condições do SO.

Para obter mais informações sobre quando o Trident+ ou o Webview2 é utilizado, consulte Browsers e controlos webview utilizados pelos Suplementos do Office.
Para obter mais informações sobre como determinar que webview está em execução, consulte Suportar webviews mais antigos da Microsoft e versões do Office

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.

Como fazer determinar se o utilizador é uma conta online ou no local?

Pode determinar se o utilizador com sessão iniciada tem uma conta Exchange Online ou conta do Exchange no local com a propriedade Office.UserProfile.accountType. Se o valor da propriedade de tipo de conta for enterprise, a caixa de correio estará num servidor Exchange no local. Tenha em atenção que o Outlook 2016 perpétuo licenciado em volume não suporta a propriedade accountType. Para contornar este problema, chame a operação ResolveNames no Exchange Web Service (EWS) no servidor do Exchange no local para obter os tipos de destinatários.

Como fazer implementar o meu suplemento no Microsoft AppSource

Se estiver a publicar um novo suplemento no Microsoft AppSource, este terá de passar por um processo de certificação. Para obter mais informações, consulte Publicar o seu Suplemento do Office no Microsoft AppSource. Se estiver a atualizar o manifesto de um suplemento que já está publicado no Microsoft AppSource, terá de passar pelo processo de certificação novamente. Pode atualizar o código fonte do suplemento no servidor Web em qualquer altura sem ter de passar pelo processo de certificação.

Se o suplemento utilizar o SSO através de NAA, o suplemento tem de estar em conformidade com as seguintes diretrizes de publicação.

Certifique-se de que processa o consentimento do administrador corretamente. Veja Publicar um suplemento que requer consentimento do administrador para os âmbitos do Microsoft Graph

Para obter detalhes adicionais sobre a implementação, consulte Disponibilizar as suas soluções no Microsoft AppSource e no Office. Se atualizar o suplemento (alterar o manifesto), terá de passar pelo processo de certificação novamente. Pode atualizar o código do servidor Web em qualquer altura sem necessidade de revisão.

Compartilhar via

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

FAQ Gerais

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