Resolvendo o problema AADSTS700054 "Response Type Not Enabled" em aplicativos do Azure AD

By Mirko Peters · 2026-04-21

Já se deparou com o erro AADSTS700054 e pensou: "O que eu fiz de errado desta vez?" Você não está sozinho. Esse erro é famoso por aparecer justamente quando você tenta autenticar um aplicativo com o Azure Active Directory, especialmente com Microsoft 365, Dynamics 365 ou suas próprias aplicações de página única. Em essência, ele significa que seu aplicativo não está configurado para aceitar o "tip

Automatically translated with AI from the original post. Read the English original

Cover: Power Platform Tenant Governance and Security Risks

Este guia explica por que isso acontece e mostra como corrigir o problema tanto em aplicativos mais antigos, baseados no implicit grant, quanto em configurações modernas que usam MSAL.js e PKCE. Você também verá boas práticas para tornar suas configurações mais seguras, além de indicações de recursos da comunidade e dicas de navegação no blog para encontrar respostas rapidamente. Ao final, seja solucionando problemas em aplicativos legados ou modernos, você saberá exatamente como resolver e evitar essa dor de cabeça comum de autenticação.

Entendendo os motivos por trás do problema AADSTS700054

O erro AADSTS700054 não é apenas mais um código enigmático da Microsoft. Na prática, é a forma que o Azure encontra de dizer: "Seu aplicativo pediu algo que ele não tem permissão para ter". Geralmente, o problema está relacionado a tipos de resposta. Quando sua aplicação tenta solicitar um token do Azure AD, mas não foi configurada para esse "fluxo" (como o implicit grant), o Azure bloqueia a requisição e exibe esse erro.

Por que isso acontece? Na maioria dos casos, o erro aparece porque o registro do seu aplicativo não tem as configurações corretas para tokens de ID, tokens de acesso, ou ambos, no endpoint de autorização. Por exemplo, imagine uma Single Page Application (SPA) tentando obter tokens pelo fluxo implícito sem que esse fluxo esteja habilitado no Azure AD. O Azure percebe essa incompatibilidade entre o que está sendo solicitado e o que é permitido, e, pronto, você recebe o AADSTS700054.

Erros de configuração são comuns na migração de abordagens de autenticação legadas para boas práticas modernas. Organizações que dão suporte a aplicativos antigos (que ainda podem usar o implicit grant) e a aplicativos novos (que deveriam usar PKCE e o fluxo de código de autorização) estão especialmente expostas. Está atualizando a autenticação na nuvem ou integrando novos serviços da Microsoft? As chances de encontrar esse obstáculo aumentam.

Entender esse erro permite conectar o que o seu código está solicitando com o que o seu aplicativo no Azure está configurado para aceitar. Por isso, ao longo do restante deste guia, você verá como alinhar as solicitações de token da sua aplicação com o que a Microsoft Identity Platform espera, deixando você um passo à frente na solução de problemas.

Habilitando a solução recomendada para problemas de tipo de resposta do implicit grant

Se o AADSTS700054 está bloqueando sua integração, a solução mais rápida geralmente é configurar o registro do aplicativo com os tipos de resposta corretos. Isso normalmente significa habilitar as configurações do implicit grant, basicamente dando permissão ao seu aplicativo para solicitar tokens diretamente do endpoint de autorização.

Veja como fazer isso no portal do Azure: primeiro, acesse "Registros de aplicativo", encontre o aplicativo afetado e abra a seção "Autenticação". Procure a área "Concessão implícita e fluxos híbridos". Ali você verá as caixas de seleção "Tokens de acesso" e "Tokens de ID". Marque as opções adequadas para o seu cenário: normalmente, SPAs precisam, no mínimo, da opção "Tokens de ID", e aplicativos mais antigos podem precisar de ambas.

Mas não marque tudo e torça para dar certo! Habilite apenas as opções de que seu aplicativo realmente precisa, mantendo a segurança em primeiro plano. Se o seu aplicativo solicita tokens pelo endpoint de autorização, como a maioria dos aplicativos baseados em navegador, essas configurações são obrigatórias. Já para outros, especialmente os que estão migrando para fluxos mais seguros (como o PKCE), talvez você nem precise mexer no implicit grant.

Depois de aplicar essas mudanças, a maioria dos problemas com o AADSTS700054 desaparece imediatamente. Se ainda assim o erro persistir, verifique novamente o escopo de permissões do aplicativo, os URIs de redirecionamento e se as alterações já foram totalmente propagadas na sua conta. Essa é a base para resolver esse erro e colocar usuários (e desenvolvedores) de volta ao trabalho.

Boas práticas de segurança para evitar configurações incorretas de tipo de resposta

Ajustar as configurações de implicit grant pode resolver um erro, sem dúvida, mas nem sempre é o plano de longo prazo mais seguro. Habilitar o implicit flow aumenta o seu risco de segurança, já que os tokens são retornados diretamente nas respostas do navegador, o que os torna potencialmente mais fáceis de interceptar. Por isso a Microsoft, e honestamente todo administrador preocupado com segurança, recomenda usar alternativas modernas, como o Authorization Code Flow com PKCE, para a maioria dos cenários, especialmente em SPAs novas ou atualizadas.

Então, quando você deve habilitar o implicit grant? Resumindo: somente se você tiver aplicativos legados ou casos especiais que exijam isso. Para todo o resto, configure seus aplicativos para usar o authorization code flow (com PKCE). Assim, os tokens ficam fora da barra de endereços do navegador e a superfície de ataque diminui consideravelmente.

Organizações que combinam Power Platform, Microsoft 365 e Dynamics 365 não podem se dar ao luxo de negligenciar essas boas práticas. Configurações incorretas de response types não apenas quebram logins, como também podem abrir portas para invasores ou gerar dores de cabeça de conformidade mais adiante. Este panorama sobre segurança e governança do Power Platform mostra por que ter controles rigorosos e conhecer bem os fluxos escolhidos realmente importa, especialmente quando desenvolvedores cidadãos adicionam aplicativos personalizados e integrações.

Resumindo: habilite somente o que for necessário, prefira o code flow com PKCE sempre que possível e proteja bem os seus registros de aplicativo como parte de uma estratégia de governança mais ampla. Garanta que todas as configurações estejam alinhadas com as políticas de segurança que você quer aplicar. Seu eu do futuro (e seus auditores) vão agradecer.

Solucionando o AADSTS700054 em aplicativos modernos usando MSAL.js

Você poderia imaginar que migrar para bibliotecas de autenticação modernas, como o MSAL.js v2+ e o PKCE, livraria você dos erros "da velha guarda", como o AADSTS700054, certo? Nem tanto. Até SPAs modernas podem ter problemas se o registro do aplicativo ou as configurações do lado do cliente não estiverem alinhados às boas práticas atuais.

O principal vilão? Premissas antigas. Desenvolvedores podem começar a usar o MSAL.js, mas manter URIs de redirecionamento legados ou, sem perceber, solicitar response types (como o id_token) que não estão habilitados no Azure AD. Isso é especialmente comum quando o manifesto do aplicativo foi copiado e colado de outro projeto. O resultado: o Azure AD devolve aquele erro terrível assim que o aplicativo inicia o fluxo de autenticação.

Como depurar isso? Abra as ferramentas de desenvolvedor do navegador, vá até a guia Rede e observe a solicitação de autorização. Verifique com atenção se o seu response_type corresponde aos fluxos que o aplicativo no Azure realmente aceita. Se você vir solicitações de tokens que não estão devidamente habilitadas, volte ao portal do Azure e ajuste o registro do aplicativo de acordo.

Não esqueça: com o MSAL.js v2 e o PKCE, normalmente você nem precisa habilitar o implicit flow. Mas, se o seu aplicativo continuar falhando, procure configurações "implicit" fixas no código, erros de digitação nos URIs de redirecionamento ou tipos de concessão incorretos. Uma revisão cuidadosa das configurações (tanto no Azure quanto no lado do cliente) resolve a maioria dos problemas. Pode não ser glamouroso, mas uma solução de problemas bem feita economiza horas de tentativa e erro.

Migrando aplicativos legados do implicit grant para o PKCE

Pronto para deixar o implicit flow para trás de vez? Boa decisão. Migrar para o PKCE (Proof Key for Code Exchange) é hoje o padrão ouro, e a Microsoft o recomenda fortemente. Mas, sejamos realistas: migrar um aplicativo em produção com usuários nunca é apenas uma troca de configuração. Você precisa de um plano que evite indisponibilidade, minimize interrupções no login e mantenha todos informados.

O primeiro passo é avaliar e inventariar todos os seus registros de aplicativo que usam implicit grant. Em seguida, teste o novo fluxo baseado em PKCE em um ambiente de homologação. Isso significa configurar o aplicativo para usar o authorization code flow, atualizar os URIs de redirecionamento e ajustar os arquivos de configuração do cliente (como as substituições do MSAL.js ou do ADAL.js). Execute o ciclo completo de login e logout e as renovações de token. Garanta que funcione para todos os tipos de usuário.

Antes de ativar a mudança em produção, tenha um plano de rollback. Talvez você precise manter os dois fluxos habilitados temporariamente caso a migração não ocorra sem problemas. Comunique claramente aos seus usuários: eles não gostam de surpresas, principalmente se o trabalho parar por causa de uma mudança não anunciada na forma de fazer login.

Por fim, fique atento a problemas como falhas na renovação de tokens ou sessões ativas interrompidas após a migração. Se possível, planeje as atualizações para horários de baixo tráfego. Precisa de mais informações sobre como operacionalizar essas transições? Embora alguns recursos sejam redirecionados, você sempre pode conferir os podcasts mais recentes sobre Microsoft 365 Copilot e arquitetura para encontrar pistas indiretas sobre gestão de mudanças em ambientes corporativos (veja as discussões recentes aqui).

Como encontrar blogs confiáveis, como o de Nishant Rana, para soluções seguras

Blog de Nishant Rana: Uma referência para resolver problemas de integração com o Azure AD. Nishant aborda cenários detalhados, correções passo a passo e até casos específicos de Dynamics 365 e Power Platform. Seus tutoriais claros tornam erros de autenticação complexos bem menos intimidantes.
Blog do MVP da KingswaySoft: Conhecido por orientações práticas sobre integração de dados de CRM, este blog liderado por MVPs aborda regularmente casos extremos de autenticação, essenciais para quem trabalha com o Azure AD e o ecossistema do Microsoft 365.
Top 100 Blogs de CRM: Listas curadas como esta destacam a comunidade técnica em geral, permitindo descobrir autores que publicam regularmente sobre identidade, segurança e solução de problemas da Microsoft. Ampliar sua lista de leitura aumenta as chances de encontrar uma solução adequada ao seu caso específico.

Como usar a pesquisa rápida e os arquivos para localizar posts recentes sobre problemas no Azure AD

Use os recursos de pesquisa rápida: a maioria dos blogs técnicos confiáveis tem uma barra de pesquisa, então use-a! Digite “AADSTS700054”, “Azure AD error” ou “implicit grant” para encontrar imediatamente posts e guias diretamente relacionados ao seu problema. Isso é bem mais rápido do que navegar manualmente.
Navegue pelos arquivos e pelas atualizações mais recentes: se você não encontrar seu problema na pesquisa, navegue pelos arquivos do site ou pelas listas filtradas de “posts mais recentes”. Muitos guias de solução de problemas consagrados ficam escondidos em conteúdos antigos, e às vezes um post recente traz exatamente a correção necessária para as novas mudanças de autenticação da plataforma da Microsoft.
Combine filtros para usuários avançados: quer ir além? Use os sistemas de tags ou categorias em conjunto com a pesquisa. Filtrar todos os posts sobre “Azure AD” ou restringir por “app registration” vai reduzir seu tempo de solução de problemas e revelar questões e soluções que você talvez deixaria passar.