AADSTS900561: erro "Endpoint only accepts POST"

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

Entenda o erro AADSTS900561 "endpoint only accepts POST", por que ele ocorre durante o login no Microsoft Entra e como solucioná-lo com segurança.

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

Resposta rápida: o erro AADSTS900561 "endpoint only accepts POST" significa que um endpoint de autenticação do Microsoft Entra recebeu uma requisição com um método não suportado. Verifique o fluxo de login da aplicação, o tratamento do redirecionamento e a URL exata que está sendo aberta, em vez de alterar repetidamente as configurações de identidade do locatário.

Já encontrou o erro AADSTS900561 ao trabalhar com o Microsoft Entra ID ou o Azure Active Directory? É aquele que diz "Endpoint only accepts POST requests". Em termos simples, o que ele significa é que sua aplicação tentou se comunicar com o serviço de autenticação da Microsoft usando uma requisição GET, mas o servidor espera uma POST. É como bater na porta dos fundos quando você deveria ter usado a da frente.

Esse erro aparece com frequência quando você está desenvolvendo ou integrando aplicações para o Microsoft 365, o Azure ou o Power Platform. Ele normalmente surge durante fluxos de login ou quando você tenta obter um token da plataforma de identidade da Microsoft. Entender o que dispara o erro AADSTS900561 é fundamental, porque ele aponta diretamente para os pontos em que suas chamadas de autenticação não estão de acordo com os requisitos técnicos da Microsoft. A seguir, vamos detalhar por que esse erro é gerado e como ele se relaciona com outro código de erro conhecido, o AADSTS90056.

Descrição e contexto dos erros AADSTS90056 e AADSTS900561

Antes de partir para a correção do AADSTS900561, vale entender exatamente com o que você está lidando. Tanto o AADSTS90056 quanto o AADSTS900561 são códigos de erro gerados pelo Microsoft Entra ID (antigo Azure AD) quando há algo errado na forma como sua aplicação se comunica com os endpoints de autenticação. Resumindo: o AADSTS90056 costuma indicar um parâmetro de autenticação incorreto ou ausente, enquanto o AADSTS900561 está focado em problemas com o método HTTP, especificamente quando você usa GET onde é exigido POST.

A plataforma de identidade do Microsoft Entra usa regras rígidas de protocolo para trocas de token e fluxos de autenticação, geralmente baseados no OAuth 2.0. Quando sua aplicação precisa obter um token chamando o endpoint /token, a Microsoft espera que você envie uma requisição POST. Não é capricho: as requisições POST permitem enviar dados sensíveis com segurança no corpo da requisição, e não na URL, reduzindo o risco de vazamentos e de registros acidentais em logs.

Já as requisições GET são como livros abertos. Elas expõem seus dados diretamente na URL, para qualquer pessoa ou proxy no caminho que queira ver. Isso é um problema de segurança, especialmente para serviços corporativos que gerenciam identidades e dados sensíveis. Por isso, a plataforma de identidade da Microsoft exige POST para qualquer ação que envolva a troca de segredos, códigos ou informações do usuário. Se você enviar um GET, a plataforma identifica a requisição e bloqueia o processo com o erro AADSTS900561. Entender esse contexto técnico ajuda não só a saber o que deu errado, mas também por que essa regra existe e por que ela é inegociável nos serviços de nuvem da Microsoft.

Em resumo, se você está vendo qualquer um desses códigos durante a autenticação, sua aplicação está fazendo uma requisição que não segue as regras. Com a noção de segurança e de fluxo de protocolo confiável por trás desses códigos, fica muito mais claro o que corrigir e por que isso importa em ambientes corporativos de aplicações.

Causas comuns e soluções para problemas de autenticação AADSTS900561

Se o AADSTS900561 está aparecendo, quase certamente há um erro na forma como sua aplicação está chamando o endpoint de token da Microsoft. Um dos principais vilões é um registro de aplicação mal configurado ou um URI de redirecionamento incorreto no Azure AD. Se o URI de redirecionamento registrado não corresponder ao que sua aplicação realmente usa, ou se estiver faltando algum detalhe obrigatório, você pode acabar disparando uma requisição GET no lugar da POST esperada.

Outro erro clássico está na forma como o próprio fluxo de autenticação foi codificado. Alguns desenvolvedores usam GET ao chamar o endpoint /token, principalmente quando montam as requisições manualmente ou não entendem bem a biblioteca que estão usando. No OAuth 2.0 com o Microsoft Entra, a obtenção final do token deve sempre ser enviada como POST, nunca como GET. Se o seu fluxo envia um GET nessa etapa, o erro AADSTS900561 vai aparecer.

Então, como resolver? Comece revisando com atenção os URIs de redirecionamento, tanto no registro do aplicativo no portal do Azure quanto na configuração local do seu app. Certifique-se de que sejam exatamente iguais, até o protocolo (http ou https) e o caminho. Se você estiver usando as bibliotecas MSAL ou ADAL, verifique se não está em uma versão antiga nem escrevendo código que sobrescreva o comportamento padrão de POST delas. Se você usa seu próprio código de autenticação, inspecione as chamadas HTTP para confirmar que o endpoint de token sempre recebe uma requisição POST.

Precisa de ajuda com o código? Aqui vai uma dica rápida: em JavaScript, usando fetch ou axios, garanta que sua chamada para /token seja algo como method: 'POST'. Se você vir "endpoint only accepts post" nos logs ou no navegador, é sinal de que precisa revisar cada etapa do código entre a autorização e a troca do token, especialmente se seu app alterna entre lógica de front-end e de back-end. Para um aprofundamento sobre riscos orientados por identidade e correções de governança no mundo real, confira este episódio sobre a identidade como plano de controle na segurança do Azure.

Depuração e boas práticas para evitar erros AADSTS900561

Vamos falar sobre rastrear esse erro e garantir que ele não volte a te assombrar. Se você executa um single page app (SPA) com React, Vue ou Angular, abra as ferramentas de desenvolvedor do navegador. Acesse a aba Rede (Network), execute seu fluxo de login e fique atento a uma requisição GET chegando ao endpoint /token. No momento em que você a encontrar, descobriu o culpado.

Às vezes, essa falha acontece porque a biblioteca de autenticação não está configurada corretamente. No MSAL.js, por exemplo, usar loginRedirect quando você queria acquireTokenSilent, ou configurar a biblioteca de forma incorreta, pode fazer com que ela dispare um GET em vez de um POST. Atualizar o MSAL.js para a versão mais recente e revisar as configurações de inicialização pode poupar muita dor de cabeça. Os frameworks são exigentes, mas a documentação da Microsoft é bem clara quanto à necessidade de POST nas requisições de token.

Não deixe de consultar também os logs do Azure. Verifique os logs de entrada do Azure AD para obter rastreamentos detalhados das requisições. Você verá qual endpoint foi chamado, qual método foi usado e quaisquer indicadores de incompatibilidade de protocolo. Se precisar de diagnósticos aprofundados, ferramentas como o Fiddler podem detalhar o tráfego HTTP linha por linha, e o Application Insights pode mapear a pilha de chamadas até o ponto do problema.

Prevenir é melhor do que remediar. Sempre teste seus fluxos de autenticação em desenvolvimento e homologação antes de levá-los para produção. Garanta que todo trecho de código que troca um código de autorização por um token seja executado no servidor, com POST, exatamente como manda o guia do OAuth 2.0. Trocar códigos no navegador é uma forma clássica de provocar o AADSTS900561 e abrir brechas de segurança.

Se você trabalha em ambientes maiores de Microsoft 365 ou Azure, vale revisar sua abordagem de governança. O Entra ID agora sustenta boa parte do acesso crítico, então manter suas políticas bem definidas e seu código alinhado às melhores práticas da Microsoft facilita muito a vida. Para saber como desenhar uma governança que não deixe nada escapar, vale muito a pena assistir a este episódio sobre estratégia de governança corporativa no Azure.

E se o seu app faz parte do Power Platform, ou simplesmente usa conectores, gerencie suas identidades e conectores com cuidado para evitar desvios de arquitetura e erros inesperados de permissão. Você encontrará orientações práticas neste recurso: melhores práticas de segurança e governança do Power Platform.

Resumindo: conheça seus fluxos de autenticação, valide cada requisição e mantenha suas ferramentas atualizadas. Se um erro escapar, você saberá exatamente onde procurar e como eliminá-lo de vez.

Checklist prático

• Confirme o resultado exato para o usuário e o escopo afetado.
• Use a configuração ou a opção de comunicação mais restrita e segura.
• Teste a experiência antes de uma implantação ampla.
• Documente responsáveis, ações de acompanhamento e pontos de revisão.

Perguntas frequentes

Qual é o melhor primeiro passo?

Identifique o cenário do usuário e o resultado específico que você precisa. Isso evita mudanças desnecessárias e produz uma implementação mais clara e confiável.

🎧 Você também deveria ouvir

• Identity Governance no Entra oferece o contexto de governança em torno da administração de identidades.
• Microsoft Entra Private Access – Simply Explained explica a arquitetura moderna de identidade e acesso.
• Privileged Identity Management (PIM) – Simply Explained acrescenta o contexto de acesso privilegiado para administradores do Entra.

Última revisão: julho de 2026.