AADSTS900561: ошибка — конечная точка принимает только POST

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

Разбираем ошибку AADSTS900561 «Endpoint only accepts POST»: почему она возникает при входе в Microsoft Entra и как безопасно её диагностировать.

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

Краткий ответ: ошибка AADSTS900561 «Endpoint only accepts POST» означает, что конечная точка аутентификации Microsoft Entra получила запрос с неподдерживаемым методом. Проверьте сценарий входа в приложении, обработку перенаправлений и точный URL, который открывается, вместо того чтобы многократно менять общие настройки удостоверений клиента.

Сталкивались с ошибкой AADSTS900561 при работе с Microsoft Entra ID или Azure Active Directory? Та самая, которая говорит: «Endpoint only accepts POST requests». Если объяснить простым языком, ваше приложение пыталось обратиться к службе аутентификации Microsoft с помощью запроса GET, а сервер ждёт POST. Это как стучаться в чёрный ход, когда нужно было зайти через парадный.

Эта ошибка часто возникает, когда вы создаёте или интегрируете приложения для Microsoft 365, Azure или Power Platform. Обычно она появляется в сценариях входа или при попытке получить токен от платформы удостоверений Microsoft. Понимание того, что вызывает AADSTS900561, очень важно, потому что это сразу показывает, где ваши запросы аутентификации не соответствуют техническим требованиям Microsoft. Дальше разберём, почему возникает эта ошибка и как она связана с другим знакомым кодом, AADSTS90056.

AADSTS90056 и AADSTS900561: описание ошибок и справочная информация

Прежде чем приступать к устранению AADSTS900561, полезно понять, с чем именно вы имеете дело. И AADSTS90056, и AADSTS900561 — это коды ошибок, которые возвращает Microsoft Entra ID (ранее Azure AD), когда что-то не так в том, как ваше приложение обращается к конечным точкам аутентификации. Если коротко: AADSTS90056 обычно указывает на неверный или отсутствующий параметр аутентификации, тогда как AADSTS900561 относится именно к проблемам с HTTP-методом, а точнее к ситуации, когда используется GET там, где требуется POST.

Microsoft Entra ID использует строгие правила протокола для обмена токенами и сценариев аутентификации, которые во многом построены на OAuth 2.0. Когда приложению нужно получить токен, обращаясь к конечной точке /token, Microsoft ожидает запрос POST. Это не придирки: POST позволяет передавать чувствительные данные безопасно, в теле запроса, а не в URL, что снижает риск утечки и случайного попадания в журналы.

А запросы GET открыты для всех. Все ваши данные попадают прямо в URL, и их может увидеть любой, кто стоит на пути, включая прокси. Это проблема безопасности, особенно для корпоративных сервисов, которые управляют удостоверениями и конфиденциальными данными. Поэтому платформа удостоверений Microsoft требует POST для любого действия, связанного с обменом секретами, кодами или данными пользователя. Если отправить GET, платформа его распознает и резко останавливает запрос с ошибкой AADSTS900561. Понимание этой технической основы помогает увидеть не только то, что вы сделали не так, но и зачем существует это правило, почему оно обязательно для всех облачных служб Microsoft.

Итак, если вы видите любой из этих кодов во время аутентификации, ваше приложение отправляет запрос, который не соответствует правилам. Понимая контекст безопасности и надёжной работы протокола, вы гораздо яснее представляете, что нужно исправить и почему это важно в профессиональной среде приложений.

Частые причины и решения проблем аутентификации AADSTS900561

Если появляется AADSTS900561, почти наверняка где-то ошибка в том, как ваше приложение обращается к конечной точке токенов Microsoft. Одна из главных причин: неверно настроенная регистрация приложения или некорректный URI перенаправления в Azure AD. Если зарегистрированный URI перенаправления не совпадает с тем, который реально использует приложение, или в нём не хватает обязательных данных, вы можете случайно вызвать GET-запрос вместо ожидаемого POST.

Ещё одна классическая ошибка связана с тем, как закодирован сам сценарий аутентификации. Некоторые разработчики по ошибке используют GET при обращении к конечной точке /token, особенно если формируют запросы вручную или неправильно понимают используемую библиотеку. В OAuth 2.0 с Microsoft Entra финальное получение токена всегда должно отправляться как POST, но никогда как GET. Если на этом шаге ваш процесс отправляет GET, ошибка AADSTS900561 появится сразу.

Так как же это исправить? Начните с двойной проверки redirect URI как в регистрации приложения на портале Azure, так и в локальной конфигурации вашего приложения. Убедитесь, что они полностью совпадают, вплоть до протокола (http или https) и пути. Если вы используете библиотеки MSAL или ADAL, проверьте, что не работаете на устаревшей версии и что в вашем коде нет переопределения стандартного поведения POST. Если вы используете собственный код аутентификации, проверьте HTTP-вызовы и убедитесь, что к конечной точке токена всегда отправляется запрос POST.

Нужна помощь с кодом? Вот быстрый совет: в JavaScript, при использовании fetch или axios, убедитесь, что ваш вызов /token выглядит примерно так: method: 'POST'. Если в логах или в браузере вы видите сообщение «endpoint only accepts post», пора проверить каждый шаг вашего кода между авторизацией и обменом токена, особенно если ваше приложение переключается между логикой фронтенда и бэкенда. Более глубокий разбор рисков, связанных с идентификацией, и практических решений по управлению читайте в этом выпуске о том, как идентификация становится control plane в безопасности Azure.

Отладка и лучшие практики предотвращения ошибок AADSTS900561

Давайте разберемся, как найти источник этой ошибки и сделать так, чтобы она больше не повторялась. Если вы работаете с одностраничным приложением (SPA) на React, Vue или Angular, откройте инструменты разработчика в браузере. Перейдите на вкладку Network, запустите процесс входа и внимательно следите за GET-запросом к конечной точке /token. Как только вы его увидите, причина найдена.

Иногда сбой возникает из-за неправильной настройки библиотеки аутентификации. Например, в MSAL.js использование loginRedirect там, где нужен acquireTokenSilent, или ошибки в конфигурации библиотеки могут приводить к отправке GET вместо POST. Обновление MSAL.js до последней версии и повторная проверка настроек инициализации могут избавить от множества проблем. Фреймворки капризны, но документация Microsoft четко говорит, что запросы токенов должны выполняться методом POST.

Не игнорируйте и журналы Azure. Проверьте журналы входов Azure AD, в них есть подробные трассировки запросов. Там видно, к какой конечной точке было обращение, каким методом и есть ли пометки о несоответствиях протокола. Для глубокой диагностики подойдут инструменты вроде Fiddler, которые разбирают HTTP-трафик построчно, а Application Insights может показать стек вызовов до проблемного места.

Профилактика лучше, чем лечение. Всегда тестируйте сценарии аутентификации в средах разработки и тестовой среде, прежде чем выпускать их в продуктив. Убедитесь, что весь код, который обменивает код авторизации на токен, выполняется на сервере методом POST, как и предписывает руководство по OAuth 2.0. Обмен кодами в браузере — классический способ получить AADSTS900561 и открыть брешь в безопасности.

Если вы работаете в крупных средах Microsoft 365 или Azure, посмотрите на свой подход к управлению. Entra ID сейчас лежит в основе многих критически важных сценариев доступа, поэтому строгие политики и код, который следует рекомендациям Microsoft, значительно упрощают жизнь. Информацию о том, как построить управление так, чтобы ничего не ускользало, стоит посмотреть в этом выпуске о стратегии корпоративного управления в Azure.

А если ваше приложение входит в состав Power Platform или просто использует коннекторы, внимательно управляйте идентификацией и коннекторами, чтобы избежать архитектурного дрейфа и неожиданных ошибок разрешений. Практические рекомендации вы найдете в этом материале: Лучшие практики безопасности и управления в Power Platform.

Итог? Знайте свои сценарии аутентификации, проверяйте каждый запрос и своевременно обновляйте инструменты. Если ошибка всё же проскочит, вы будете точно знать, где искать, и сможете раз и навсегда её устранить.

Практический чек-лист

• Уточните, какой результат получит пользователь и какие области затронуты.
• Выберите наиболее узкую безопасную конфигурацию или способ коммуникации.
• Протестируйте сценарий перед широким развёртыванием.
• Зафиксируйте ответственных, последующие действия и точки пересмотра.

Часто задаваемые вопросы

Какой первый шаг самый правильный?

Определите пользовательский сценарий и конкретный результат, который вам нужен. Это исключит ненужные изменения и поможет получить более понятную и надежную реализацию.

🎧 Вам также стоит послушать

• Identity Governance in Entra даёт контекст управления для администрирования идентичностей.
• Microsoft Entra Private Access – Simply Explained объясняет современную архитектуру идентичностей и доступа.
• Privileged Identity Management (PIM) – Simply Explained добавляет контекст привилегированного доступа для администраторов Entra.

Последнее обновление: июль 2026 г.