Користувач не дав усіх дозволів: як OAuth-застосунок має працювати з частковим доступом

Одна знята позначка не повинна вимикати читання

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

OAuth — це спосіб надати одному застосунку обмежений доступ до даних або дій в іншому сервісі без передавання пароля. Ним користуються люди, які підключають сторонні застосунки, і розробники інтеграцій: так можна погодити лише потрібні дії та не відкривати весь обліковий запис.

20 серпня 2026 року Cloudflare представила можливість відмовитися від необов’язкових дозволів на екрані згоди. Це свіжий приклад ширшого правила: запитано — не означає надано. Застосунок має визначити фактичний доступ і залишити в роботі функції, для яких цього доступу достатньо.

Хто бере участь у наданні доступу

Розгляньмо інтеграцію із сервісом завдань. У цьому сценарії є чотири ролі OAuth:

• Користувач, або власник ресурсу, вирішує, до яких завдань і дій надати доступ.
• Клієнтський застосунок — асистент, який хоче читати або змінювати завдання.
• Сервер авторизації обробляє запит і рішення користувача та видає передбачені потоком дані для доступу.
• Сервер ресурсів приймає захищені запити й перевіряє токен та право на конкретну операцію.

Токен доступу (access token) — це видана сервером авторизації цифрова перепустка, яку клієнт передає серверу ресурсів. Це не пароль і не доказ необмеженого доступу. Можливості токена залежать від наданих прав, строку дії та правил провайдера. Закінчення дії й відкликання токена також відбуваються за механізмом конкретного провайдера.

Межі доступу часто задають дозволи (scopes). Наприклад, tasks.read може дозволяти читання, а tasks.write — редагування. Назви та точне значення дозволів визначає провайдер.

П’ять наборів дозволів, які не можна плутати

Під час проєктування інтеграції корисно розрізняти п’ять наборів. Конкретний провайдер може не називати або не показувати кожен із них окремо.

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

У реалізації Cloudflare, описаній 20 серпня, власник клієнта може позначити частину налаштованих дозволів як необов’язкові. Під час конкретного потоку оцінюються лише запитані дозволи: користувач може відмовитися від необов’язкових, а незапитані не показуються й не вимагаються. Це поведінка Cloudflare, а не універсальний вигляд екрана OAuth.

У нашому прикладі читання налаштовано, запитано, визнано обов’язковим і надано. Редагування також налаштовано й запитано, але для підсумовування воно необов’язкове, і користувач його не надав. Адміністрування взагалі не запитується. Такий частково наданий доступ (partial grant) є нормальним результатом, якщо основне завдання може працювати далі.

Перевіряйте надане, а не припускайте його

У потоці OAuth 2.0 з кодом авторизації клієнт обмінює короткочасний одноразовий код на токен доступу. За розділом 5.1 RFC 6749 поле scope у відповіді з токеном можна пропустити, якщо наданий набір збігається із запитаним. Якщо набори відрізняються, це поле обов’язкове.

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

Після перевірки застосунок може вибрати поведінку за простою схемою:

Результат доступу	Читання	Редагування	Поведінка застосунку
Повний	Працює	Працює	Усі погоджені функції доступні
Частковий	Працює	Недоступне	Режим читання й точне пояснення обмеження
Бракує обов’язкового дозволу	Не працює	Недоступне	Пояснити причину й дати вибір повторити згоду або скасувати підключення

Так застосунок дотримується принципу найменших привілеїв (least privilege): асистент для підсумовування не отримує право редагувати чи адмініструвати дані про всяк випадок.

Від розуміння до безпечної перевірки з ШІ-агентом

ШІ-агент може допомогти дослідити й протестувати модель лише після того, як людина сама зрозуміла різницю між запитаними та наданими дозволами.

1. Зрозумійте модель

• Контекст і межі. Дайте агенту лише цю статтю та вигаданий список дозволів. Він може пояснювати терміни й ставити контрольні запитання. Забороніть радити зміни в реальному OAuth-клієнті та приписувати всім провайдерам однакову поведінку.
• Зупинка, результат і перевірка. Не рухайтеся далі, доки не поясните різницю між запитаним і наданим доступом своїми словами. Результат — ваше коротке пояснення. Звірте його з визначенням OAuth, ролями та п’ятьма наборами вище.

2. Дослідіть матеріали без змін

• Контекст і межі. Використовуйте заредаговану конфігурацію клієнта, офіційну документацію та приклад відповіді тестового сервера без секретів, кодів, чинних токенів і персональних даних. Агент може лише виписувати й порівнювати дозволи. Мережеві виклики, редагування та робочі облікові дані заборонені.
• Зупинка, результат і перевірка. Зупиніться, якщо з’явився секрет або не знайдено визначеного провайдером джерела фактичних дозволів. Результат — перелік функцій із полями «налаштовано», «запитано», «обов’язковий або необов’язковий» і «надано». Перевірте кожне поле вручну за вихідними матеріалами.

3. Сплануйте поведінку

• Контекст і межі. Передайте агенту перевірений перелік та опис потрібних функцій. Він може запропонувати поведінку для повного, часткового й відхиленого доступу та скласти план тестів. Забороніть додавати нові дозволи, змінювати робоче середовище чи оголошувати необов’язковий дозвіл необхідним без продуктової причини.
• Зупинка, результат і перевірка. Зупиніться, якщо команда не може визначити мінімальний дозвіл для основного завдання. Результат — погоджена схема поведінки та план тестів. Їх мають окремо переглянути власник функції й фахівець із безпеки.

4. Дійте лише в ізоляції

• Контекст і межі. Використовуйте одноразовий OAuth-клієнт, тестову організацію або локальне середовище із синтетичними даними й мінімальним кодом. Агент може підготувати перевірку дозволів, тести та локально їх запустити. Заборонені розгортання в робочому середовищі, зовнішні виклики, секрети, згода від імені користувача й реальні адміністративні дії.
• Зупинка, результат і перевірка. Зупиніться при несподіваному записі, зверненні до реального акаунта, розширенні привілеїв або втраті ізоляції. Результат — патч, тести та журнал запуску. Перегляньте код вручну й повторіть сценарії повного, часткового та нульового доступу.

5. Перевірте незалежно

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

6. Поясніть результат

• Контекст і межі. Передайте агенту погоджену схему, результати тестів і явно позначені особливості провайдера. Він може підготувати повідомлення користувачеві та короткий запис рішення. Забороніть приховувати обмеження, обіцяти неперевірені функції чи подавати реалізацію Cloudflare як вимогу OAuth.
• Зупинка, результат і перевірка. Зупиніться, якщо лишилася невирішена розбіжність або текст обіцяє дію без потрібного дозволу. Результат мають переглянути розробник, фахівець із безпеки та людина, яка раніше не вивчала OAuth.

Частковий доступ має бути зрозумілим

Цей підхід підходить для хмарної інтеграції, програми командного рядка (CLI), сервера Model Context Protocol (MCP), через який ШІ використовує зовнішні інструменти, та самого ШІ-асистента. Запитуйте мінімум, перевіряйте фактично надане й вимикайте лише залежні функції. Тоді відмова від редагування не завадить читанню, а згода залишиться справжнім вибором користувача.

Джерела

• IETF — The OAuth 2.0 Authorization Framework, RFC 6749
• IETF — OAuth 2.0 Token Revocation, RFC 7009
• Cloudflare — From all-or-nothing to task-based OAuth consent