Що таке OAuth? «Увійти через Google» і делегований доступ пояснено

OAuth — це відкритий стандарт, який дає користувачеві змогу надати одному застосунку обмежений доступ до свого облікового запису в іншому сервісі без передачі пароля. Коли ви натискаєте «Підключити Google Календар» і бачите екран із запитанням «Дозволити цьому застосунку бачити ваші події?», — це OAuth. Застосунок отримує токен саме для того, що ви погодили, і ви можете відкликати його будь-коли. Той самий механізм, з додатковим шаром під назвою OpenID Connect, забезпечує роботу кнопки «Увійти через Google» та подібних.

Чому OAuth важливий, коли ви створюєте з ШІ

OAuth з'являється у двох поширених ситуаціях, коли ви створюєте застосунок:

1. Вхід через соцмережі. Ви хочете, щоб користувачі входили через «Увійти через Google» (або Apple, Microsoft, GitHub), а не створювали ще один пароль. Див. як додати вхід до вашого застосунку.
2. Під'єднання до облікових записів користувачів в інших сервісах. Вашому застосунку потрібно читати календар користувача, публікувати в його соцмережі, отримувати файли з хмарного диска або синхронізувати бухгалтерські дані.

В обох випадках ваш конструктор ШІ може написати код, але деякі кроки може виконати лише ви: створити застосунок розробника у провайдера, отримати client ID і client secret, зареєструвати URL зворотного виклику і для деяких дозволів пройти перевірку провайдера. Розуміння того, як працює OAuth, робить ці кроки — і помилки, які вони викликають, — значно менш таємничими. Щоб побачити ширшу картину входу, див. що таке автентифікація.

Повсякденна аналогія

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

• Адміністратор на стійці — це сервер авторизації (сторінка входу Google).
• Перевірка вашої особи — це ваш вхід в Google.
• Картка-ключ — це токен доступу.
• «Лише номер і спортзал» — це області доступу, які ви погодили.
• Виїзд — це закінчення строку дії токена або ваше відкликання доступу.

Застосунок, яким ви користуєтеся, ніколи не бачить вашого пароля від Google, лише картку-ключ.

Як працює OAuth, крок за кроком

Найпоширеніший потік для вебзастосунків — потік авторизаційного коду. Ось що відбувається, коли користувач під'єднує свій Google Календар до застосунку для планування:

1. Клік. Користувач натискає «Підключити Google Календар».
2. Переадресація до провайдера. Застосунок відправляє браузер до Google з client ID, областями доступу, які він хоче (читання подій календаря), і redirect URI — адресою, куди Google має повернути користувача.
3. Вхід і згода. Користувач входить в Google (якщо ще не увійшов) і бачить екран згоди зі списком того, що просить застосунок. Він натискає «Дозволити».
4. Назад з кодом. Google переадресовує браузер на redirect URI застосунку з короткочасним одноразовим авторизаційним кодом.
5. Обмін на сервері. Сервер застосунку надсилає цей код разом із client secret безпосередньо до Google і отримує токен доступу (і часто токен оновлення).
6. Використання API. Сервер викликає API Google Календаря з токеном доступу і отримує події користувача.

Зворотний виклик на кроці 4 виглядає приблизно так:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

А відповідь із токеном на кроці 5 — це JSON на кшталт:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Важлива ідея дизайну: обмін токенами відбувається сервер-сервер, тож client secret і токени ніколи не мають проходити через браузер.

OAuth проти OpenID Connect проти власного входу

Багато застосунків поєднують їх: вхід за email і паролем, плюс «Увійти через Google» через OIDC, плюс окремі підключення OAuth до інших сервісів.

Ключові терміни

Поширені хибні уявлення

• «OAuth — це система входу». Звичайний OAuth надає доступ; OpenID Connect відповідає за ідентичність. Використання голого токена доступу як доказу того, хто є користувачем, уже призводило до реальних помилок безпеки.
• «Застосунок отримує мій пароль». Ніколи. У цьому й суть.
• «Запитувати більше областей доступу — безпечно». Користувачі насторожено ставляться до широких запитів, а провайдери на кшталт Google можуть вимагати перевірки застосунку для чутливих або обмежених областей. Просіть лише те, що справді потрібно.
• «Client secret можна покласти у фронтенд». Усе, що є в коді браузера, є публічним. Тримайте його в серверних секретах.
• «Працює в тестах — працюватиме і в продакшні». Провайдери часто обмежують неперевірені застосунки — наприклад, списком тестових користувачів — а redirect URI для вашого живого домену потрібно реєструвати окремо.
• «Токени діють вічно». Токени доступу швидко спливають, а користувачі можуть відкликати доступ. Ваш застосунок має коректно обробляти обидві ситуації.

Що запитати у вашого конструктора ШІ

• «Додай «Увійти через Google» з використанням OpenID Connect і добре підтриманої бібліотеки автентифікації — не пиши потік OAuth з нуля.»
• «Використовуй потік авторизаційного коду з PKCE і перевіряй параметр state.»
• «Читай client ID і client secret зі змінних середовища на сервері.»
• «Запитуй лише потрібні області доступу: доступ лише для читання календаря.»
• «Перелічи всі redirect URL, які мені треба зареєструвати в консолі провайдера: для попереднього перегляду, опублікованої адреси та мого власного домену.»
• «Зберігай токени оновлення в базі даних у зашифрованому вигляді, а прострочені або відкликані токени обробляй, просячи користувача підключитися знову.»
• «Дай користувачам змогу від'єднати інтеграцію на сторінці налаштувань.»

OAuth і Mythex

У Mythex немає вбудованого входу для кінцевих користувачів застосунків, які ви створюєте; документація описує підхід «принеси свій»: ви обираєте бібліотеку автентифікації або хостинговий провайдер, зберігаєте її ключі як секрети проєкту, а агент пише код. У рецепті додавання автентифікації є стартовий промпт для цього. Ви також зустрінете OAuth у самому Mythex: можна зареєструватися через Google, підключення GitHub для синхронізації репозиторію використовує OAuth GitHub, а ШІ-клієнти, які підключаються до Mythex через MCP, проходять через сторінку згоди OAuth. Більше див. що таке автентифікація і що таке двофакторна автентифікація.

Запитання