Розв’язання помилки AADSTS900144 (відсутній параметр) в Azure AD

By Mirko Peters · 2026-04-21

Ніхто не любить натикатися на глуху стіну через помилки автентифікації, але помилка AADSTS900144 про відсутній параметр в Azure AD — одна з тих класичних перешкод, що дратують усіх: від розробників застосунків до ІТ-адміністраторів. Ця стаття пояснює, що саме стоїть за цією помилкою, що перевірити насамперед і які кроки допоможуть знову відкрити доступ користувачам. Ми розглянемо причини та способ

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

Cover: Fix Microsoft Teams Governance Sprawl with Enforced Decisions

Незалежно від того, підтримуєте ви Microsoft 365, Azure, Power Platform чи будь-яке рішення, яке підключається до Entra ID, тут ви знайдете поради щодо виправлень як на боці клієнта, так і на боці сервера. Практичне усунення несправностей, перевірені на практиці найкращі методи для корпоративного середовища та додаткові посилання на матеріали про управління хмарою допоможуть уникнути проблем, коли ця помилка знову з’явиться.

Чому з’являється «AADSTS900144» під час автентифікації в Azure AD?

Помилка «AADSTS900144: Request body must contain the following parameter» з’являється, коли в запиті автентифікації, надісланому до Azure Active Directory (або Microsoft Entra ID), бракує важливих даних. Простими словами, Azure шукає в запиті на токен такі відомості, як grant_type або client_id, і не може їх знайти — або ж вони є, але мають неправильний формат чи розміщені не там.

Ця помилка найчастіше трапляється в потоках OAuth 2.0, особливо коли користувачі або застосунки намагаються увійти через корпоративні хмарні сервіси. Зазвичай причина в тому, що щось не так із параметрами тіла запиту, які надсилаються під час обміну коду авторизації на токен. Якщо обов’язковий параметр пропущено, написано з помилкою або розміщено поза очікуваним тілом POST-запиту, Azure AD зупиняє обробку, і з’являється код AADSTS900144.

Ви можете побачити цю помилку під час інтеграції власних бізнес-застосунків, реєстрації нових застосунків в Azure або коли настільні клієнти (наприклад, Microsoft Teams) стикаються з проблемами автентифікації. Іноді навіть помилка під час копіювання чи швидка зміна реєстрації застосунку призводять до того, що параметр перестає відповідати очікуванням. Повідомлення про помилку може виглядати загадково, але фактично Azure каже: «Поверніться, перевірте свій запит і виправте те, чого бракує».

Для тих, хто працює з багатоклієнтними застосунками, варто знати, що невідповідності в контексті клієнта або в кінцевих точках служб можуть призводити до схожої плутанини, інколи створюючи враження, ніби бракує параметра, хоча насправді він просто спрямований не туди. Розуміння цих механізмів прискорює діагностику та робить роботу служб підтримки менш стресовою.

Типові проблеми з параметрами тіла запиту та швидкі виправлення

Помилка AADSTS900144 майже завжди зводиться до того, що в запиті на токен щось пропущено або розміщено не на місці. Ключові параметри, як-от client_id та grant_type, — типові винуватці. Якщо застосунок пропускає хоча б один обов’язковий параметр, кінцева точка токенів Azure AD просто відхиляє запит. Переконайтеся, що використовуєте метод HTTP POST, адже GET та інші методи тут не підійдуть.

Спочатку переконайтеся, що застосунок надсилає запити з типом вмісту application/x-www-form-urlencoded. Дивно, як часто неправильний тип вмісту змушує Azure AD шукати параметри, яких вона не може прочитати. Далі відкрийте будь-який інструмент для HTTP-запитів (Postman, curl або навіть Fiddler) і перегляньте необроблене тіло запиту: чи справді client_id, grant_type, client_secret та інші параметри є в корисному навантаженні, а не в значеннях рядка запиту чи прихованими в заголовках?

Якщо ви змінюєте реєстрацію застосунку, пам’ятайте, що очікувані параметри можуть залежати від типу потоку надання доступу. Наприклад, для потоку з кодом авторизації потрібно також передати code. Це не завжди очевидно, тому перед тим, як вважати питання закритим, завжди звіряйте тип надання доступу з документацією Azure.

У багатоорендних застосунках остерігайтеся надсилання запитів на кінцеву точку /common, якщо вашому цільовому клієнту потрібен конкретний GUID або значення, — інакше ваша «відсутня змінна» може бути просто неправильно спрямованим запитом. Надсилання запитів на хибну адресу, особливо в міжорендних сценаріях, може збити з пантелику навіть досвідчених розробників, тож завжди перевіряйте кінцеву точку та параметри разом. Виправте їх, і в більшості випадків жахлива помилка AADSTS900144 зникне просто на очах.

Усунення несправностей на боці клієнта: очищення кешованих облікових даних і скидання застосунків

Іноді справа не у вашому коді, а в локальному комп'ютері, який ламає процес автентифікації. Кешовані облікові дані та старі cookie можуть зберігати застарілі токени або пошкоджувати дані параметрів, особливо в настільних застосунках на кшталт Microsoft Teams чи Outlook. Коли так відбувається, користувачі продовжують бачити повідомлення AADSTS900144, навіть після виправлення проблем на серверному боці.

Найпростіший перший крок — очистити збережені облікові дані. У Windows скористайтеся Диспетчером облікових даних, щоб видалити кешовані токени, пов'язані з вашим обліковим записом. У веб-застосунках видалення файлів cookie та даних сайту в браузері може запустити чистий процес повторної автентифікації. Для впертих проблем, особливо в Microsoft Teams, спробуйте локальне скидання: вийдіть з облікового запису на всіх пристроях, закрийте застосунок, видаліть папки кешу й перезапустіть його. Деяким користувачам може знадобитися примусово видалити профіль облікового запису Teams у налаштуваннях пристрою, щоб гарантовано прибрати всі сліди, а потім перевстановити Teams з нуля.

Якщо ви допомагаєте іншим, надайте просту послідовність дій: очистити облікові дані, закрити застосунок, очистити кеш, а потім знову увійти. Так зводяться до мінімуму простої та плутанина для бізнес-користувачів, яким просто потрібно, щоб їхні застосунки знову працювали. Команди ІТ-підтримки мають завжди переконатися, що всі старі дані автентифікації видалено, перш ніж копати глибше, адже залишки «сміття» є однією з головних причин стійких помилок AADSTS900144.

Для тих, хто займається управлінням Microsoft Teams або повторюваними проблемами автентифікації, варто усвідомити, що самих лише технічних виправлень недостатньо, щоб «вирішити» питання управління. Щоб глибше зрозуміти, чому управління ніколи не є фінішною прямою і як зробити його дієвим на практиці, ознайомтеся з цим посібником про управління Teams і ілюзію контролю або перегляньте цей плейбук з автоматизації життєвого циклу Teams з практичними стратегіями.

Найкращі практики запобігання AADSTS900144 у корпоративних застосунках

Запобігання помилці AADSTS900144 насправді зводиться до дисципліни щодо запитів OAuth та конфігурацій застосунків. Звичкою має стати перевірка всіх обов'язкових параметрів, особливо client_id і grant_type, перед надсиланням запитів до кінцевої точки токенів Azure AD. Автоматизовані перевірки у вашому конвеєрі розгортання можуть виявити відсутні або некоректні параметри до того, як вони потраплять у продакшн, і заощадити купу тікетів згодом.

Використовуйте інструменти розробника Microsoft Entra ID, щоб імітувати запити автентифікації та побачити, що бачить Azure AD. Це допомагає виявити не лише відсутні параметри, а й невідповідні кінцеві точки чи політики, які можуть блокувати коректні запити в окремих клієнтах. Налаштування модульних тестів з імітованими кінцевими точками Entra ID ще більше зменшить несподіванки, виявляючи проблеми з параметрами на етапі розробки, а не під час запуску.

Для організацій зі складним управлінням або кількома командами розробки інтегруйте перевірки в практики інфраструктури як коду. Використовуйте перевірку схем у шаблонах розгортання ARM або Bicep, щоб вимагати наявності всіх обов'язкових параметрів OAuth під час реєстрації застосунку. Це зменшує ризик дрейфу конфігурацій і помилок налаштування, особливо коли застосунки розвиваються.

Для підходу, орієнтованого на безпеку, стежте за наданням згоди OAuth і застосуванням політик. Зловмисники полюбляють експлуатувати надто м'які налаштування згоди, тож обмежте згоду користувачів, вимагайте схвалених видавців і застосовуйте адміністративні робочі процеси. Для ґрунтовного огляду цих загроз і способів їх пом'якшення прочитайте цей розбір атак згоди OAuth в Entra ID. Якщо ви вдосконалюєте процеси управління, варто скористатися автоматизацією, RBAC і Azure Policies. Див. цю стратегічну настанову з корпоративного управління Azure з архітектурними рішеннями та практичними засобами контролю.