Что такое OAuth? «Войти через Google» и делегированный доступ простыми словами

OAuth — открытый стандарт, который позволяет пользователю дать одному приложению ограниченный доступ к своему аккаунту в другом сервисе, не передавая ему пароль. Когда вы нажимаете «Подключить Google Календарь» и видите экран «Разрешить этому приложению видеть ваши события?», — это и есть OAuth. Приложение получает токен только на то, что вы одобрили, и вы можете отозвать его в любой момент. Тот же механизм с дополнительным слоем OpenID Connect лежит в основе «Войти через Google» и похожих кнопок.

Почему OAuth важен при создании приложений с ИИ

OAuth встречается в двух типичных ситуациях, когда вы создаёте приложение:

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

В обоих случаях ваш конструктор ИИ может написать код, но некоторые шаги может выполнить только вы: создать приложение разработчика у провайдера, получить client ID и client secret, зарегистрировать адреса обратного вызова и для некоторых разрешений пройти проверку провайдера. Понимание того, как работает OAuth, делает эти шаги и связанные с ними ошибки куда менее загадочными. Общую картину входа см. в что такое аутентификация.

Бытовая аналогия

Представьте карту-ключ в отеле. На стойке регистрации вам подтверждают личность и выдают карту, которая открывает ваш номер и спортзал — но не другие номера и не служебные помещения — и перестаёт работать при выезде. Карта не содержит вашего паспорта. Если вы её потеряете, стойка аннулирует её и выдаст новую.

• Стойка регистрации — сервер авторизации (страница входа Google).
• Проверка личности — вход в аккаунт Google.
• Карта-ключ — токен доступа.
• «Только номер и спортзал» — области доступа (scopes), которые вы одобрили.
• Выезд — истечение срока токена или ваш отзыв доступа.

Приложение, которым вы пользуетесь, никогда не видит пароль от Google, только карту-ключ.

Как работает OAuth, шаг за шагом

Самый распространённый поток для веб-приложений — поток с кодом авторизации. Вот что происходит, когда пользователь подключает свой Google Календарь к приложению для записи:

1. Нажатие. Пользователь нажимает «Подключить Google Календарь».
2. Перенаправление к провайдеру. Приложение отправляет браузер в Google с его client ID, запрошенными областями доступа (чтение событий календаря) и адресом перенаправления (redirect URI), куда Google вернёт пользователя.
3. Вход и согласие. Пользователь входит в Google (если ещё не вошёл) и видит экран согласия со списком запрошенного. Он нажимает «Разрешить».
4. Возврат с кодом. Google перенаправляет браузер на адрес приложения с коротким одноразовым кодом авторизации.
5. Обмен на сервере. Сервер приложения отправляет этот код вместе с клиентским секретом напрямую в 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"
}

Важная мысль в дизайне: обмен токеном происходит между серверами, поэтому клиентский секрет и токены никогда не нужно передавать через браузер.

OAuth, OpenID Connect и собственный вход

Многие приложения комбинируют их: вход по почте и паролю, плюс «Войти через Google» через OIDC, плюс отдельные подключения OAuth к другим сервисам.

Ключевые термины

Частые заблуждения

• «OAuth — это система входа». Обычный OAuth предоставляет доступ; идентификацией занимается OpenID Connect. Использование голого токена доступа как доказательства того, кто перед вами, уже приводило к реальным уязвимостям.
• «Приложение получает мой пароль». Нет, никогда. В этом и смысл.
• «Запрашивать больше областей доступа безвредно». Пользователи настороженно относятся к широким запросам, а такие провайдеры, как Google, могут требовать проверку приложения для чувствительных или ограниченных областей. Запрашивайте только то, что нужно.
• «Клиентский секрет можно положить во фронтенд». Всё, что есть в коде браузера, публично. Храните его в секретах на стороне сервера.
• «Работает в тестах — значит, будет работать в продакшене». Провайдеры часто ограничивают неподтверждённые приложения, например списком тестовых пользователей, а адрес перенаправления для вашего боевого домена нужно регистрировать отдельно.
• «Токены действуют вечно». Токены доступа быстро истекают, а пользователи могут отозвать доступ. Ваше приложение должно корректно обрабатывать и то, и другое.

Что попросить у конструктора ИИ

• «Добавь вход через Google с OpenID Connect, используя хорошо поддерживаемую библиотеку аутентификации — не пиши поток OAuth вручную.»
• «Используй поток с кодом авторизации и PKCE, и проверяй параметр state.»
• «Читай client ID и client secret из переменных окружения на сервере.»
• «Запрашивай только нужные области доступа: только чтение календаря.»
• «Перечисли все адреса перенаправления, которые нужно зарегистрировать в консоли провайдера: для предпросмотра, для опубликованного адреса и для собственного домена.»
• «Храни токены обновления в базе в зашифрованном виде, а для истёкших или отозванных токенов просить пользователя подключиться заново.»
• «Дай пользователям возможность отключить интеграцию на странице настроек.»

OAuth и Mythex

Встроенного входа для конечных пользователей в приложениях, которые вы создаёте в Mythex, нет; в документации описан подход «приведи свой»: вы выбираете библиотеку аутентификации или хостируемого провайдера, сохраняете её ключи как секреты проекта, а код пишет агент. В рецепте добавления аутентификации есть стартовый запрос для этого. С OAuth вы также встретитесь в самом Mythex: войти можно через Google, подключение GitHub для синхронизации репозитория использует OAuth GitHub, а ИИ-клиенты, которые подключаются к Mythex по MCP, проходят через страницу согласия OAuth. Подробнее см. что такое аутентификация и что такое двухфакторная аутентификация.

Вопросы