Impossível entrar no Outlook.com (erro AADSTS900561): causas, diagnóstico e solução

Ao tentar entrar no Outlook.com, alguns usuários encontram o erro AADSTS900561. Este guia explica por que ele ocorre (GET vs POST), como diagnosticar a causa (navegador, proxy, IdP) e traz passos práticos de mitigação e quando escalar ao suporte de identidade da Microsoft.

Índice

Visão geral do problema

Um provedor de internet relatou que vários clientes, ao iniciar sessão no Outlook.com, passam a ver a mensagem:

AADSTS900561: The endpoint only accepts POST requests. Received a GET request.

Limpeza de cache/cookies, habilitar cookies de terceiros, testar em Chrome/Edge/Firefox/Opera e incluir o domínio nas zonas confiáveis não resolveram. A análise indica que se trata de um comportamento do Azure Active Directory (atual Microsoft Entra ID), geralmente fora do alcance de simples ajustes de navegador.

O que de fato significa o erro AADSTS900561

O código AADSTS900561 é emitido quando o serviço de identidade recebe uma requisição GET em um endpoint que só aceita POST (tipicamente o endpoint de token em fluxos OAuth 2.0/OIDC). Isto pode acontecer por três grupos de causas:

Alteração do método HTTP no caminho: proxies, VPNs, WAFs, balanceadores, “aceleradores” ou extensões de navegador que reescrevem a requisição por motivos de cache/inspeção.
Pré‑busca e automação do cliente: recursos de prefetch/prerender, bookmarks antigos, preenchimento automático ou aplicativos que disparam navegação GET direto em uma URL que deveria ser usada via POST.
Configuração incorreta de aplicativo/IdP: redirecionamentos, endpoints ou bindings (WS‑Federation/SAML/OAuth) configurados para o método errado.

O que significa o erro?	Descrição simplificada
POST obrigatório no endpoint de token	O serviço de identidade recusa requisições GET no endpoint de emissão de tokens. Se um GET chegar por alteração de rede, prefetch, bookmark ou má configuração, o Azure AD retorna `AADSTS900561`.

Como funciona o login (e onde o erro aparece)

De forma muito resumida, o fluxo moderno de autenticação web funciona assim:

O navegador acessa a página de entrada (ex.: outlook.live.com).
O serviço redireciona para o provedor de identidade (OIDC/OAuth/WS‑Fed) com uma requisição GET de autorização (parâmetros como clientid, redirecturi, scope).
Após o usuário se autenticar, o cliente troca um código de autorização por token via requisição POST ao endpoint de token.

O AADSTS900561 surge exatamente na etapa de troca de código por token, quando algo converte o POST em GET ou dispara um GET indevido no endpoint de token.

Contexto do Outlook.com e contas pessoais vs. corporativas

Para contas pessoais Microsoft (MSA), o fluxo padrão de entrada do outlook.live.com costuma envolver endpoints de conta pessoal. No entanto, há cenários em que domínios corporativos, contas conectadas ou políticas de login acabam envolvendo o Azure AD/Entra ID. Se você está vendo AADSTS, é um forte indício de que o fluxo passou por um endpoint do Azure AD, seja por conta corporativa/escolar, seja por uma integração/encaminhamento.

Solução oficial indicada no tópico original

O caso foi classificado como assunto de Azure Active Directory. A orientação foi abrir a questão no canal oficial de suporte (portal do Azure ou comunidade técnica específica) para que um engenheiro de identidade analise logs e a topologia (aplicativo, proxies, IdP federado) e indique a correção apropriada.

Passos práticos e rápidos de mitigação

Use o fluxo padrão de login: acesse outlook.live.com ou www.office.com e clique em Entrar. Evite links salvos que apontem diretamente para URLs de redirecionamento OAuth/SAML.
Teste em sessão anônima (InPrivate/Incógnito) e preferencialmente em outro dispositivo ou rede. Isso isola interferências de cache, extensões e políticas locais.
Desative temporariamente proxies, VPNs, filtros ou “aceleradores”. Alguns dispositivos/regras transformam POST em GET para cache/inspeção.
Verifique provedores de identidade federados (ADFS, Shibboleth, Ping, etc.). Confirme que o binding e o endpoint configurados para falar com o Azure AD estão usando POST conforme a especificação.

Quadro de diagnóstico rápido

Sintoma	Causa provável	Como validar	Ação imediata
Erro aparece só em rede corporativa	Proxy/WAF reescrevendo método	Captura via DevTools/Fiddler mostra GET no endpoint de token	Excluir domínio da cache/inspeção, ajustar política para preservar POST
Erro só no navegador principal	Extensão de privacidade/performance	Teste em modo anônimo e sem extensões	Desativar extensão ou criar exceção
Erro ao usar bookmark antigo	URL de redirecionamento desatualizada	Abrir `outlook.live.com` > Entrar	Atualizar favoritos para a página de entrada
Domínio federado	Binding/endpoint errado no IdP	Revisar metadados e método exigido	Corrigir configuração do IdP (POST)

Como confirmar se um POST virou GET

DevTools (Chrome/Edge/Firefox)

Abrir a página de entrada.
Pressionar F12 e ir à aba Network.
Reproduzir o login e filtrar por “token” ou “oauth” na busca.
Selecionar a requisição ao endpoint de token e verificar o campo Request Method. Se estiver GET, encontrou a causa.
Salvar um HAR (export network log) para anexar ao suporte.

Fiddler/Proxies de captura

Inicie a captura, reproduza o erro e preserve o tráfego TLS apenas se a política de segurança permitir.
Confirme, na timeline, se a chamada ao endpoint de token está como GET.
Salve a sessão (.saz) para o engenheiro de identidade.

Teste programático (ilustrativo)

Compare os dois comandos a seguir (apenas para entender a diferença de método; não execute contra serviços de produção sem autorização):

# Exemplo de GET indevido (provoca AADSTS900561)
curl -v "https://<tenant>/oauth2/v2.0/token?clientid=...&granttype=authorization_code"

Exemplo correto com POST

curl -v -X POST "https\://\/oauth2/v2.0/token" 
-H "Content-Type: application/x-www-form-urlencoded" 
\--data "client\id=...&grant\type=authorization\code&code=...&redirect\uri=..."

Extensões e recursos do navegador que podem interferir

Bloqueadores/otimizadores: extensões que interceptam requisições para “economia de dados” ou “aceleração”.
Privacidade e anti‑rastreio: ferramentas que reescrevem métodos, removem cabeçalhos ou body de POST.
Prefetch/Prerender: mecanismos que fazem GET antecipado em URLs vistas anteriormente.

Mitigação: testar sem extensões; criar exceções para domínios Microsoft; desabilitar prefetch/prerender; esvaziar cache e dados do site.

Infra de rede: onde normalmente o método é alterado

Em ambientes corporativos e de provedores, os seguintes componentes são suspeitos comuns:

Proxies HTTP(s) e WAFs com regras de normalização/armazenamento que só cacheiam GET e, inadvertidamente, reescrevem POST para GET.
Gateways de inspeção TLS que não preservam integralmente cabeçalhos/corpos de POST.
Balanceadores de carga com políticas agressivas de “HTTP to HTTPS redirect” aplicadas de maneira genérica a qualquer caminho, incluindo o endpoint de token.

Mitigação: criar bypass/exceção para endpoints de autenticação (sem reescrita de método nem cache), garantir pass-through de POST, revisar regras de inspeção e normalização.

IdP federado (ADFS, Shibboleth etc.)

Se seu domínio é federado, verifique:

O binding configurado para o retorno ao Azure AD/cliente (HTTP-POST vs. Redirect).
O endpoint correto para cada protocolo (WS‑Federation/SAML/OAuth/OIDC) e se está exigindo POST onde apropriado.
Redirecionamentos intermediários que troquem método (ex.: 302 seguido de GET em uma URL que deveria receber POST).

Quando escalar para o time de identidade (Azure AD/Entra ID)

Se após os testes o erro persistir, reúna evidências e acione o suporte. Inclua:

Correlation ID (e, se exibidos, Trace ID, Timestamp, Tenant ID).
HAR/SAZ com a Request Method do endpoint de token mostrando GET.
Topologia: existe proxy/VPN/WAF? Há inspeção TLS? Qual o IdP? O domínio é federado?
Escopo: afeta todos os usuários? Só em uma rede? Só em um navegador?

Dado a coletar	Onde obter	Por quê é útil
Correlation ID + Timestamp	Página de erro em tela	Permite ao engenheiro cruzar com logs de back-end
HAR/SAZ	DevTools, Fiddler	Prova objetiva de que um POST virou GET
Lista de middleboxes	Inventário de rede	Identifica quem pode estar reescrevendo requisições
Config. do IdP	Console do ADFS/Shibboleth/etc.	Verifica binding, endpoints e redirecionamentos

Checklist de correção e prevenção

Substitua favoritos/links antigos por a página de entrada oficial (ex.: outlook.live.com > Entrar).
Teste sem extensões e, se necessário, crie exceções para domínios Microsoft.
Implemente bypass em proxies/WAFs para endpoints de autenticação (sem cache e sem reescrita de método).
Garanta que o IdP usa HTTP-POST onde requerido e que não há redirecionamentos que troquem o método.
Mantenha navegadores e middleboxes atualizados e com políticas compatíveis com OAuth/OIDC.

Cenários comuns e como fechá-los rapidamente

Usuários domésticos afetados ao mesmo tempo

Se vários clientes do mesmo ISP reportam o erro simultaneamente, suspeite de uma alteração recente no cache/proxy do provedor. Uma política de “cachear sempre que possível” pode estar forçando GET em caminhos sensíveis. O alívio imediato é remover a interferência (regra/bypass) e invalidar caches.

Somente máquinas gerenciadas pelo trabalho

Neste caso, foque em Endpoint Protection, filtragem de conteúdo, inspeção TLS e PAC file (configuração automática de proxy). Um teste de comparação em rede móvel (tethering) ajuda a confirmar.

Organização com domínio federado

Revise metadados/assinaturas do IdP e o método de retorno. Erros intermitentes costumam apontar para redirecionamentos intermediários (HTTP 302) que induzem o navegador a refazer a chamada como GET em vez de encaminhar o corpo POST.

Perguntas frequentes

Limpar cache e cookies resolve? Às vezes, mas não quando a alteração do método ocorre na rede ou no IdP. É um bom primeiro passo, não a solução definitiva.

É problema do Outlook.com? Nem sempre. O Outlook.com apenas inicia o fluxo; o erro é lançado pelo serviço de identidade ao receber um método inválido no endpoint de token.

Por que aparece só em um navegador? Extensões e recursos como prefetch podem ser específicos de um perfil. Compare com sessão anônima e outro navegador.

É seguro desativar inspeção TLS? Em ambientes regulados, faça bypass apenas para domínios de autenticação, seguindo a política de segurança da sua organização.

Modelo de relato para abrir no suporte

Resumo: Erro AADSTS900561 ao entrar no Outlook.com
Escopo: X usuários / rede Y / desde DD/MM/AAAA
Padrão: Reproduzido em navegador A/B; some em rede móvel
IDs: Correlation ID = <GUID>; Timestamp = AAAA-MM-DDTHH:MM:SSZ
Evidências: HAR/SAZ em anexo (endpoint de token com Request Method = GET)
Topologia: Proxy/WAF <nome e versão>; IdP <ADFS/Shibboleth/etc.>; políticas relevantes
Ação já tentada: limpar cache, anônimo, desativar extensões, bypass parcial no proxy

Resumo executivo

O que está acontecendo: o endpoint de token do Azure AD/Entra ID aceita somente POST. Quando uma etapa do caminho (navegador, extensão, proxy, WAF ou IdP) envia GET, o serviço retorna AADSTS900561.

Como corrigir rápido: use o fluxo padrão de entrada partindo da página principal, teste sem extensões e sem middleboxes, e aplique bypass em proxies/WAFs para endpoints de autenticação.

Quando escalar: se persistir, colete Correlation ID, timestamp e um HAR/SAZ demonstrando o método incorreto e abra um chamado com o time de identidade (Azure AD/Entra).

Passo a passo recomendado (para copiar e executar)

Entrar por outlook.live.com > Entrar.
Repetir o teste em janela anônima e em outra rede (ex.: hotspot móvel).
Se resolver fora da rede corporativa: criar exceção de proxy/WAF e validar.
Se persistir: desativar extensões de privacidade/performance e validar.
Se o domínio for federado: revisar binding/endpoint do IdP para POST.
Coletar Correlation ID + HAR/SAZ e abrir o chamado no suporte de identidade.

Conclusão

O erro AADSTS900561 não é um “bug do Outlook.com”, mas um mecanismo de proteção do provedor de identidade contra chamadas com método errado no endpoint de token. Seguindo o roteiro acima, você identifica rapidamente se a causa está no cliente (extensões/URLs antigas), na rede (proxy/WAF/VPN) ou na configuração de federação (IdP), e consegue restaurar o login com segurança. Quando necessário, escale com evidências claras para o time de identidade, que poderá indicar a correção exata para o seu cenário.

Resumo do tópico original: o caso foi redirecionado ao suporte de Azure AD/Entra ID. Para resolver, confirme se alguma etapa da rede ou do IdP está trocando POST por GET e, se necessário, envolva o suporte com logs completos (Correlation ID, timestamp e captura de tráfego).