Розуміння помилки AADSTS70000 Invalid Grant у Microsoft Azure та M365

By Mirko Peters · 2026-04-21

Помилка AADSTS70000 «invalid grant» – типова проблема для адміністраторів і розробників, які працюють з Azure Active Directory та службами Microsoft 365. Ви часто побачите її під час підключення систем або автоматизацій через Power Platform, надбудови Outlook або застосунки, що використовують потоки автентифікації Microsoft.

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

Cover: Fix Conditional Access Loopholes in Microsoft 365

Простіше кажучи, помилка AADSTS70000 означає, що під час автентифікації щось пішло не так – зазвичай тоді, коли застосунок або користувач намагається отримати токен через OAuth, але «грант» уже не дійсний. Через це може зупинитися робочий процес Power Automate, зламатися інтеграція з Outlook або перестати працювати вхід до будь-якого застосунку, що використовує Azure чи Entra ID для автентифікації. Якщо ви працюєте в хмарних ІТ або розробці застосунків, цю помилку варто сприймати серйозно: вона сигналізує про проблеми автентифікації та безпеки, які можуть повністю зупинити ваші системи.

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

Розбираємо частини повідомлення про помилку 70000 Invalid Grant

Коли ви стикаєтеся з помилкою AADSTS70000 invalid grant, насправді ви бачите дві ключові частини повідомлення про помилку. Перша – це сам код помилки «AADSTS70000». Цей код вказує саме на проблеми з грантами OAuth у механізмі автентифікації Microsoft.

Друга частина – це причина, яка зазвичай позначена як «invalid_grant» або супроводжується повідомленням на кшталт «grant is invalid or malformed». Це означає, що сервер не зміг прийняти запит на токен, як правило через неправильні налаштування, політики безпеки або проблеми зі структурою гранта.

Якщо ця помилка з’являється в журналах входу Azure, іноді там можуть бути додаткові деталі, наприклад «refresh token expired» або «redirect URI mismatch». Навчившись розпізнавати ці шаблони, ви швидше відокремлюватимете помилки користувачів, проблеми з реєстрацією застосунків і глибші неправильні налаштування служб – це скорочує час діагностики та одразу веде до найкорисніших документів Microsoft і каналів підтримки.

Що спричиняє помилку 70000 Invalid Grant?

Ось найпоширеніші причини, через які може з’явитися помилка AADSTS70000 invalid grant. Кожна з них пов’язана з тим, як OAuth і Azure AD обробляють токени, безпеку та налаштування реєстрації застосунків:

Некоректні або прострочені гранти OAuth: Недійсні або прострочені токени доступу та оновлення є провідною причиною. Якщо токен використовується після закінчення терміну дії або був змінений під час передавання, Azure AD одразу його відхиляє.
Неправильні URI перенаправлення або невідповідність клієнтських налаштувань: Незначні відмінності в зареєстрованому URI перенаправлення (навіть відсутня косою риска) можуть зламати процес. Типова причина – зміна параметрів застосунку без оновлення налаштувань Azure AD.
Проблеми з токенами оновлення: Спроба повторно використати відкликаний токен оновлення або токен, що прострочений чи виданий для іншого клієнта, викликає цю помилку. Інколи адміністратори оновлюють секрети чи скидають паролі й випадково анулюють ці токени.
Переривання політиками Conditional Access і MFA: Якщо правило MFA або відповідності пристрою спрацьовує посеред процесу – особливо для фонових або службових облікових записів, – грант відхиляється без докладного пояснення. Це непомітна причина, яка часто спантеличує навіть досвідчених фахівців. Потрібно глибше розібратися з політиками Conditional Access і питаннями довіри? Перегляньте це обговорення прогалин у політиках і найкращих практик.
Невідповідність дозволів або областей доступу: Коли дозволи відкликано, надано частково або області застосунку застаріли, раніше працюючі інтеграції можуть раптово перестати працювати. Адміністраторам і розробникам, які інтегрують сторонні застосунки, варто перевірити, що потрібні дозволи та згода адміністратора досі чинні. Детальніше про ризик згоди OAuth у Entra ID читайте на цій сторінці.

Шляхи вирішення для помилки 70000 Invalid Grant

Очистьте кешовані токени та пройдіть автентифікацію повторно: Найшвидший спосіб усунути проблеми з токенами або сеансами — відключити та знову підключити уражений обліковий запис або службу. Для Power Automate, Outlook та подібних застосунків ручний вихід і повторний вхід можуть запустити новий потік OAuth і усунути помилки invalid grant.
Перевірте та виправте URI перенаправлення: Перейдіть до Azure Portal і переконайтеся, що URI перенаправлення у реєстрації вашого застосунку точно відповідає тому, що надсилає застосунок або конектор. Навіть один зайвий символ може зірвати всю автентифікацію, коли Azure перевіряє запит.
Перевірте реєстрацію застосунку та клієнтські секрети: Переконайтеся, що всі останні зміни в реєстрації застосунку, ротації секретів і зміни дозволів актуальні. Прострочені або невідповідні клієнтські секрети тихо руйнують інтеграції, які працюють постійно.
Перегляньте політики умовного доступу та згоду: Перевірте політики умовного доступу на надмірно широкі винятки або прогалини у відповідності пристроїв — вони можуть зупинити потоки без жодного очевидного повідомлення про помилку. Посильте процеси надання згоди користувачами та переконайтеся, що згода адміністратора й далі вимагається там, де це потрібно. Щодо стратегій управління див. цей детальний посібник із найкращих практик безпеки.
Оновіть області дозволів: Ще раз перевірте області дозволів, які запитує ваш застосунок або автоматизація. Області іноді змінюють назви або визнаються застарілими, особливо в Microsoft Graph. Переконайтеся, що все узгоджується між кодом застосунку, реєстрацією на порталі та історією згоди.
Примусово очистьте токени після змін у безпеці: Якщо токени могли бути скомпрометовані або ви щойно оновили політики паролів, скористайтеся Intune або Azure Portal, щоб відкликати всі активні сеанси й запропонувати всім користувачам і автоматизаціям виконати новий вхід. Щоб дізнатися більше про протидію постійним атакам доступу через згоду, перегляньте цей посібник про ризики атак через згоду в Entra ID та способи їх пом'якшення.

Проблема Power Automate: усунення неполадок збоїв автентифікації invalid grant

Повторно підключіть або оновіть уражені джерела даних: Якщо ваш потік видає помилку 70000, почніть з того, що відкрийте потік у Power Automate, знайдіть підключення з попередженнями та просто повторно підключіть їх. Це змушує службу отримати новий токен з останніми обліковими даними.
Перевірте дозволи користувача та дійсність облікових даних: Переконайтеся, що користувач, призначений для вашого потоку, має належний доступ до джерела даних. Якщо обліковий запис, який використовується в потоці, вимкнено, строк дії пароля минув або змінилися вимоги MFA, ви побачите постійні збої автентифікації.
Перевірте обов'язкові області дозволів: Ще раз переконайтеся, що надані області відповідають тому, що потрібно вашому потоку для читання чи надсилання електронних листів, створення файлів або додавання елементів до SharePoint. Це особливо важливо для конекторів Outlook і Teams.
Перегляньте політики DLP і обмеження конекторів: Політики запобігання втраті даних (DLP) можуть непомітно зупинити потоки, якщо конектор переходить із розблокованого стану в заблокований або адміністратори змінюють його класифікацію. Щоб дізнатися більше про побудову стабільних автоматизацій із правильними межами DLP, ознайомтеся з цим посібником із політик DLP для розробників Power Platform.
Розрізняйте тимчасові та постійні збої: Іноді помилка 70000 є наслідком короткочасних перебоїв або збоїв служби. Одиничний збій із подальшим відновленням зазвичай не є приводом для тривоги, але якщо помилка повторюється, почніть перевіряти дозволи підключень і області згоди в усьому клієнті.
Перегляньте конфігурацію управління: Прогалини в управлінні середовищами або ідентифікацією з часом можуть дозволити ризикам автентифікації непомітно накопичуватися. Щоб отримати поради щодо управління Power Platform, зверніться до цього огляду найкращих практик.

Помилка входу Azure 70000: використання журналів Azure AD та аудиту для діагностики

Почніть із журналів входу Azure AD: Перейдіть до журналів входу в Azure Portal і відфільтруйте збої з кодом «AADSTS70000». Перевірте причину збою, клієнтський застосунок і вихідну IP-адресу. Це допоможе з'ясувати, чи проблема пов'язана з користувачем, застосунком або конфігурацією.
Аналізуйте шаблони поведінки токенів і клієнтів: Шукайте повторювані помилки, пов’язані з тим самим користувачем, обліковим записом служби (service principal) або застосунком. Стабільні помилки « invalid grant » після запланованої події (наприклад, ротації секрету) часто вказують на неузгоджені політики токенів або на прострочені refresh-токени.
Використовуйте журнали аудиту Azure AD для ширшого контексту: Поєднуйте невдалі входи з журналами аудиту Azure AD. Вони показують зміни в реєстраціях застосунків, оновлення політик умовного доступу та можливі масові відкликання токенів. Виявлення змін, що відбулися безпосередньо перед початком помилок, може одразу привести вас до першопричини.
Скористайтеся розширеними інструментами аудиту: Для ширших розслідувань у межах Microsoft 365 такі інструменти, як Microsoft Purview Audit, забезпечують довше зберігання даних і детальні сигнали для криміналістичного аналізу. Дізнатися, як налаштувати й використовувати ці інструменти, можна в огляді Purview Audit.
Зміцнюйте управління для довгострокової стабільності: Належне управління допомагає запобігати тихим збоям і поступовому накопиченню дрейфу політик. Встановлюйте запобіжні обмеження за допомогою Azure Policy і відстежуйте винятки. Щоб ознайомитися з комплексною стратегією, перегляньте посібник з управління Azure для підприємств.

Синхронізація часу та розбіжність годинника: прихована причина помилок OAuth invalid grant

Одна з найчастіше пропущених причин помилок AADSTS70000 invalid grant — просте розсинхронізування системного годинника, відоме як clock skew. Коли годинник вашого клієнтського комп’ютера і серверів Microsoft показують різний час, токени OAuth і коди авторизації можуть здаватися простроченими або ще не чинними, навіть якщо все інше налаштовано правильно.

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

Рішення? Регулярно синхронізуйте всі пристрої з надійним сервером NTP. Налаштуйте автоматичне коригування часу на контролерах домену, віртуальних машинах і пристроях кінцевих користувачів. Тримати відхилення в межах хвилини-двох від «реального часу» завжди краще, ніж мати справу з таємничими збоями видачі токенів. Щоб ознайомитися з ширшим підходом до проактивної безпеки Microsoft 365 і Dynamics (зокрема з адаптивними елементами керування), перегляньте цей подкаст про Zero Trust by Design.