OAuth 2.0: как работает вход через Google и GitHub без своего пароля

Каждый раз, когда приложение просит придумать новый логин и пароль, часть пользователей закрывает вкладку. Особенно если речь идёт о маленьком pet-проекте, игре или тестовом сервисе. Люди устали от десятков паролей, от вопросов «как минимум восемь символов, одна заглавная и цифра», от необходимости подтверждать email и запоминать очередную комбинацию.

OAuth 2.0 решает эту проблему. Это протокол, который позволяет войти в твоё приложение через уже существующий аккаунт — Google, GitHub, Yandex или другой провайдер. Пользователь не вводит пароль на твоём сайте, не передаёт его тебе и не создаёт новую учётную запись. Он просто нажимает «Войти через Google», разрешает доступ на стороне Google, а твоё приложение получает подтверждение личности. Ниже — простыми словами, как работает OAuth 2.0, чем он отличается от авторизации по коду или паролю, зачем это вайбкодеру и как добавить такой вход в свой проект с помощью ИИ-агента.

Что такое OAuth 2.0 простыми словами

OAuth 2.0 — это протокол авторизации. В бытовом смысле: это договорённость между твоим приложением, пользователем и крупным сервисом вроде Google или GitHub. Благодаря этой договорённости пользователь может подтвердить свою личность на знакомом ему сайте, а твоё приложение получит минимум нужной информации — обычно email, имя и уникальный идентификатор.

Заходишь в клуб, где тебя не знают. Вместо того чтобы заполнять анкету и придумывать клубный пароль, показываешь паспорт, выданный государством. Клуб сверяет, что паспорт настоящий, и пропускает тебя. При этом клуб не хранит твой паспорт, не знает твоих паролей от банка и не может выдать себя за тебя. OAuth работает примерно так же: в роли паспорта выступает аккаунт у провайдера, а в роли клуба — твоё приложение.

Важно: OAuth не передаёт твоему сервису пароль от Google. Пользователь вводит пароль только на странице Google. Твоё приложение получает специальный токен — короткую строку, подтверждающую, что Google распознал пользователя и разрешил тебе узнать о нём определённые данные. Это существенно повышает безопасность: даже если твоё приложение взломают, пароля от Google там не найдут.

Чем OAuth отличается от OTP, сессий и своих паролей

В курсе мы уже разбирали авторизацию через OTP, сессии и токены. Там пользователь проходит аутентификацию прямо в твоём приложении: вводит email, получает код, вводит код, и сервис сам проверяет, что код правильный. Подробнее об этом можно почитать в статье «Авторизация: OTP, сессии, токены».

В случае с OAuth всё по-другому. Проверку личности берёт на себя внешний провайдер. Пользователь не создаёт пароль для твоего приложения, не запоминает новый логин и не получает от тебя одноразовые коды. Он использует аккаунт, который у него уже есть.

Это не значит, что OAuth полностью заменяет собственную авторизацию. В некоторых случаях важно иметь полный контроль над процессом: например, если ты делаешь банковское приложение или сервис, где нужна верификация по паспорту. Но для большинства pet-проектов, игр, блогов и магазинов OAuth снижает трение при регистрации и улучшает безопасность.

Как технически устроен вход через Google

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

Участники процесса

• Пользователь — человек, который хочет войти в твоё приложение.
• Твоё приложение — клиент в терминах OAuth. Это сайт или приложение, куда пользователь хочет попасть.
• Провайдер — Google, GitHub, Yandex или другой сервис, у которого есть аккаунт пользователя.
• Сервер авторизации провайдера — специальный сервис провайдера, который проверяет личность и выдаёт токены.

Шаги входа

1. Пользователь нажимает кнопку «Войти через Google» на твоём сайте.
2. Твоё приложение перенаправляет пользователя на специальную страницу Google.
3. Google спрашивает пользователя: «Разрешить приложению SuchApp узнать ваш email и имя?».
4. Пользователь соглашается.
5. Google перенаправляет пользователя обратно на твоё приложение и передаёт короткий код.
6. Твоё приложение обменивает этот код на токен доступа через запрос к серверу Google.
7. По токену твоё приложение запрашивает у Google email, имя и идентификатор пользователя.
8. Твоё приложение создаёт или находит в своей базе запись пользователя и открывает сессию.

Весь процесс занимает несколько секунд. Пользователь видит только кнопку, страницу Google и возврат обратно. Технические детали происходят «под капотом».

flowchart TB
    A["Кнопка: войти через Google"] --> B["Перенаправление на страницу Google"]
    B --> C["Пользователь разрешает доступ"]
    C --> D["Google возвращает код"]
    D --> E["Приложение меняет код на токен"]
    E --> F["По токену получаем email и имя"]

Что такое redirect URI

Redirect URI — это адрес в твоём приложении, куда провайдер вернёт пользователя после авторизации. Его нужно заранее указать в консоли провайдера. Например, https://myapp.com/auth/callback. Если адрес не совпадает с тем, что отправляет твоё приложение, Google откажет во входе. Это защита: провайдер убеждается, что код уходит именно тому приложению, которое зарегистрировано.

Что такое scopes

Scope — это разрешения, которые запрашивает твоё приложение. Например, email и profile дают доступ к email и имени пользователя. Можно запросить и больше — доступ к календарю, диску, контактам, — но чем меньше запросов, тем выше доверие пользователя. Для входа обычно достаточно email и profile.

Зачем OAuth вайбкодеру на курсе

На курсе по вайбкодингу основная цель — быстро собрать работающий продукт. OAuth помогает в нескольких направлениях.

Снижает порог входа

Одна кнопка «Войти через Google» намного проще, чем форма регистрации с email, паролем, подтверждением почты и восстановлением пароля. Меньше трения на старте — больше пользователей доходят до главной функции приложения.

Снимает ответственность за хранение паролей

Когда приложение хранит пароли пользователей, перед ним стоят серьёзные требования к безопасности: хеширование, защита от перебора, безопасное восстановление, соблюдение требований регуляторов. С OAuth всё это берёт на себя провайдер. Тебе не нужно заботиться о том, утёк ли пароль, потому что пароля у тебя нет.

Ускоряет разработку

Вместо того чтобы писать с нуля систему регистрации, авторизации, восстановления пароля и подтверждения email, можно подключить готовую библиотеку и настроить OAuth за короткое время. Это особенно ценно на этапе MVP, когда важно проверить идею, а не строить идеальную инфраструктуру.

Повышает доверие

Пользователи доверяют знакомым брендам. Кнопка «Войти через Google» или «Войти через GitHub» выглядит безопаснее, чем неизвестная форма на маленьком сайте. Это особенно важно для новичков, у которых пока нет узнаваемого бренда.

Как попросить ИИ-агента добавить OAuth в проект

Вайбкодеру не обязательно разбираться во всех деталях протокола. Достаточно понимать общий принцип и уметь поставить задачу ИИ-ассистенту.

Готовые библиотеки

Для популярных фреймворков существуют библиотеки, которые берут на себя рутину OAuth. Например:

• Для Next.js — NextAuth.js, позже переименованная в Auth.js. Она поддерживает множество провайдеров из коробки: Google, GitHub, Yandex, Discord и другие.
• Для проектов на Supabase — встроенный Supabase Auth, который тоже умеет работать с OAuth-провайдерами.
• Для React-приложений без Next.js — можно использовать специализированные клиентские библиотеки, но тогда часть логики придётся делать на сервере.

Пример запроса к ИИ-агенту

Вместо общего «добавь вход через Google» лучше дать конкретный список шагов:

• Подключи Auth.js к Next.js-приложению.
• Настрой провайдера Google: зарегистрируй приложение в Google Cloud Console, получи Client ID и Client Secret, сохрани их в .env.
• Добавь кнопку «Войти через Google» на странице входа.
• После успешного входа сохрани пользователя в базу данных: email, имя, provider, providerAccountId.
• Сделай так, чтобы email использовался только если email_verified равно true.
• Настрой защищённые страницы: без авторизации показывать только лендинг и форму входа.

Чем конкретнее запрос, тем меньше догадок делает агент и тем меньше ошибок появляется в коде.

Что нужно подготовить вручную

Даже если код пишет ИИ, некоторые действия придётся сделать самому:

1. Создать приложение в консоли провайдера: Google Cloud Console, GitHub Settings, Yandex OAuth и т.д.
2. Получить Client ID и Client Secret.
3. Указать разрешённые redirect URI.
4. Добавить тестовых пользователей, если приложение ещё не прошло модерацию провайдера.

Эти шаги зависят от интерфейса провайдера, поэтому ИИ-агент может лишь подсказать общий путь. Актуальные скриншоты и расположение кнопок лучше смотреть в официальной документации.

Частые ошибки новичков

OAuth упрощает жизнь, но у него есть свои подводные камни. Вот самые распространённые ошибки.

Путать OAuth с простой авторизацией по паролю

Иногда новички думают, что OAuth — это способ узнать пароль пользователя от Google. Это не так. Пароль остаётся у Google. Твоё приложение получает только токен и разрешённые данные. Если ты хочешь, чтобы пользователь заходил именно по твоему паролю, OAuth не подходит — нужна своя система.

Забыть настроить redirect URI

Самая частая техническая ошибка — неправильно указанный redirect URI. Если в консоли Google указан https://myapp.com/auth/callback, а приложение отправляет http://localhost:3000/auth/callback, авторизация не сработает. Особенно важно следить за протоколом http vs https и за www vs без www.

Не проверять email_verified

Google может вернуть email пользователя, но не факт, что он подтверждён. Если использовать неподтверждённый email для создания аккаунта, злоумышленник сможет войти под чужим адресом. Поэтому перед созданием пользователя важно проверять поле email_verified.

Запрашивать слишком много прав

Если приложению нужен только вход, не стоит запрашивать доступ к Google Drive, календарю и почте. Лишние scope отпугивают пользователей и увеличивают риски. Запрашивай минимум необходимого.

Хранить секреты в коде

Client ID можно показывать на клиенте, а вот Client Secret — настоящий секрет. Его нельзя вставлять в публичный код или отправлять в браузер. Храни его в переменных окружения на сервере. Про хранение секретов мы говорили в статье «Хранение секретов и токенов», а основы взаимодействия с внешними сервисами разбирали в «Что такое API».

Не думать о выходе из аккаунта

Вход — это только половина дела. Нужно также предусмотреть выход: очистить сессию, удалить cookies, инвалидировать токен. Иначе пользователь останется авторизованным даже после нажатия «Выйти».

Ограничения и риски

OAuth удобен, но не лишён недостатков. Прежде чем делать его единственным способом входа, есть несколько моментов, которые влияют на решение.

Зависимость от провайдера

Если Google временно недоступен или заблокирован в регионе пользователя, войти в твоё приложение через Google не получится. Это особенно актуально для пользователей из России: доступность Google и GitHub может зависеть от VPN и текущих ограничений.

Не все провайдеры доступны из России

Некоторые OAuth-провайдеры требуют, чтобы пользователь мог открыть их сайт. Если сайт заблокирован, кнопка входа не сработает. Поэтому для аудитории из России полезно предусмотреть альтернативные способы входа. Например, в курсе мы разбирали подключение «Сбер ID» — российский провайдер, который работает без VPN.

Потеря доступа к аккаунту провайдера

Если пользователь удалит свой Google-аккаунт или потеряет к нему доступ, он не сможет войти и в твоё приложение. Это риск, которого нет у классической регистрации по email. Частично проблему решает привязка нескольких провайдеров к одному аккаунту.

Ограниченный контроль

С OAuth ты не контролируешь процесс аутентификации. Если провайдер изменит правила, интерфейс или набор возвращаемых данных, придётся адаптироваться. Например, провайдер может перестать возвращать дату рождения или потребовать дополнительной модерации приложения.

Модерация приложения

Крупные провайдеры, особенно Google, требуют верификации приложения, если оно запрашивает доступ к чувствительным данным. Для базового входа по email это обычно не требуется, но стоит быть готовым к тому, что интерфейс консоли и требования могут меняться.

Честный вывод

OAuth 2.0 — это удобный способ уменьшить трение при регистрации и снять с себя часть ответственности за безопасность паролей. Для pet-проектов, игр, блогов, небольших сервисов и MVP — это часто лучший выбор. Пользователи входят одной кнопкой, тебе не нужно строить сложную систему аутентификации, а риски утечки паролей минимальны.

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

Для вайбкодера главное — уметь поставить задачу. Скажи ИИ-агенту: «Подключи вход через Google через Auth.js, настрой redirect URI, сохрани пользователя в базу и проверяй email_verified». Зная общий принцип, ты сможешь быстро добавить OAuth в проект и сосредоточиться на его уникальной функциональности, а не на рутине регистрации.

OAuth и база данных

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

База данных в твоём приложении и аккаунт у провайдера — разные вещи. OAuth лишь доказывает, что пользователь владеет определённым аккаунтом. Твоё приложение само решает, какие права давать этому пользователю: обычный пользователь, администратор, гость.

Для типичных проектов курса, где используются таблицы пользователей, заказов и рекордов, лучше всего подходят реляционные базы. Подробнее про их устройство и выбор можно почитать в статье «Базы данных для новичка». OAuth добавляется поверх: пользователь входит через Google, а данные сохраняются в PostgreSQL или Supabase.

Пример данных, которые получает приложение

После успешной авторизации Google возвращает примерно такой набор данных:

{
  "sub": "1234567890",
  "name": "Иван Петров",
  "given_name": "Иван",
  "family_name": "Петров",
  "picture": "https://lh3.googleusercontent.com/...",
  "email": "ivan@example.com",
  "email_verified": true
}

Поле sub — это уникальный идентификатор пользователя у провайдера. Именно его стоит использовать для связи аккаунта Google с записью в твоей базе данных. Email может измениться, имя может измениться, но sub остаётся постоянным.

Поле email_verified deserves особого внимания. Если оно равно false, значит пользователь ещё не подтвердил email в Google. Создавать полноценный аккаунт в твоём приложении на основе такого email рискованно: злоумышленник мог указать чужой адрес.

OpenID Connect: как OAuth превращается в вход

Часто, говоря «вход через Google», имеют в виду не чистый OAuth 2.0, а протокол OpenID Connect, который работает поверх OAuth 2.0. Для вайбкодера разница не критична, но полезно знать термин.

OAuth 2.0 изначально задумывался как механизм делегирования прав доступа. Например, приложение просит разрешение публиковать посты от имени пользователя в социальной сети. OpenID Connect добавляет к этому слой идентификации: провайдер возвращает стандартизированный набор данных о пользователе, включая идентификатор, имя и email.

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

Сравнение популярных провайдеров

Выбор провайдеров зависит от аудитории. Для международного продукта хороши Google и GitHub. Для российских пользователей важно добавить локальные варианты. Часто имеет смысл оставить несколько кнопок: пользователь сам выберет удобный способ.

Как OAuth выглядит для пользователя

С точки зрения пользователя процесс очень прост:

1. Он заходит на твой сайт и видит кнопку «Войти через Google».
2. Нажимает кнопку.
3. Попадает на страницу Google, где видит название твоего приложения и список запрашиваемых данных.
4. Нажимает «Разрешить».
5. Возвращается обратно и уже авторизован.

Если он уже авторизован в Google в этом браузере, часто достаточно одного клика. Это и есть главное преимущество: минимум усилий, максимум привычности.

OAuth и безопасность: на что обратить внимание

Хотя OAuth снимает часть рисков, он не делает приложение автоматически безопасным. Вот базовые правила:

• Всегда используй HTTPS для redirect URI. По HTTP передавать токены нельзя.
• Проверяй state-параметр, чтобы защититься от CSRF-атак. Библиотеки вроде Auth.js делают это автоматически.
• Храни Client Secret в переменных окружения, а не в коде.
• Проверяй email_verified перед созданием аккаунта.
• Не запрашивай лишних scope.
• Делай выход из аккаунта: очищай сессию и cookies.

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

Пошаговый чек-лист внедрения OAuth

Чтобы не запутаться, разбей задачу на этапы:

1. Выбери провайдеров под свою аудиторию.
2. Зарегистрируй приложение в консоли каждого провайдера.
3. Получи Client ID и Client Secret.
4. Укажи redirect URI: для локальной разработки и для продакшена.
5. Установи подходящую библиотеку: Auth.js, Supabase Auth или другую.
6. Настрой переменные окружения с секретами.
7. Добавь кнопки входа в интерфейс.
8. Напиши обработчик callback, который получает код, меняет его на токен и создаёт пользователя.
9. Проверяй email_verified перед созданием аккаунта.
10. Настрой защищённые маршруты: доступ только для авторизованных пользователей.
11. Реализуй выход из аккаунта.
12. Протестируй сценарии: первый вход, повторный вход, отказ в разрешении, удаление доступа у провайдера.

Такой чек-лист поможет и тебе, и ИИ-агенту не пропустить важные шаги.

OAuth в приложениях без Next.js

Auth.js и NextAuth чаще всего встречаются в экосистеме Next.js. Если ты используешь другой фреймворк — например, обычный React, Vue или Svelte — логика OAuth всё равно остаётся той же, но детали реализации могут отличаться.

Главное правило: секретные операции — обмен кода на токен — должны происходить на сервере, а не в браузере. В браузере можно хранить только публичный Client ID и перенаправлять пользователя на страницу провайдера. Обмен кода на токен требует Client Secret, который нельзя показывать клиенту.

Поэтому в простых приложениях без серверного фреймворка удобнее использовать готовые backend-as-a-service вроде Supabase Auth. Ты настраиваешь провайдеров в панели Supabase, а фронтенд вызывает готовые методы. Это сильно упрощает задачу и уменьшает риск ошибок с безопасностью.

OAuth на мобильных приложениях

Принцип OAuth работает не только в вебе, но и в мобильных приложениях. Пользователь нажимает кнопку в приложении, его перенаправляют в браузер или в нативное приложение провайдера, после подтверждения возвращают обратно с кодом.

В мобильной разработке важно правильно настроить deep link — специальную ссылку, по которой приложение открывается после авторизации. Без deep link код авторизации может потеряться, и пользователь останется неавторизованным. Про deep links мы говорили в статье «Deep link: открыть приложение по ссылке».

Как отлаживать ошибки OAuth

Самые частые проблемы и способы их решения:

• redirect_uri_mismatch — проверь, что redirect URI в консоли провайдера точно совпадает с тем, что отправляет приложение, включая протокол и слеш в конце.
• invalid_client — скорее всего, неверный Client ID или Client Secret, или secret используется на клиенте вместо сервера.
• access_denied — пользователь нажал «Отмена» на странице провайдера. Обработай этот случай красиво, не показывая ошибку как сбой.
• invalid_grant — код истёк или уже был использован. Коды обычно живут несколько минут и пригодны для одного обмена.
• Пользователь не создаётся в базе — проверь, что приложение правильно парсит ответ провайдера и сохраняет sub как уникальный идентификатор.

Логируй ошибки на сервере, но не показывай пользователю чувствительные детали вроде Client Secret.

OAuth и приватность пользователя

Когда ты используешь OAuth, ты получаешь доступ к личным данным пользователя. Даже если это только email и имя, это персональные данные. Важно:

• запрашивать минимум необходимой информации;
• хранить данные безопасно;
• давать пользователю возможность удалить аккаунт;
• публиковать понятную политику конфиденциальности.

Для проектов с международной аудиторией могут действовать требования GDPR и других регуляций. Даже если твой проект маленький, привычка минимизировать сбор данных поможет избежать проблем в будущем.

OAuth и роли пользователей

OAuth доказывает, что пользователь владеет аккаунтом, но не говорит, какие права у него в твоём приложении. Роли — администратор, модератор, обычный пользователь — задаёшь ты сам в своей базе данных.

Обычно после первого входа через OAuth пользователю присваивается роль по умолчанию, например user. Если нужно сделать кого-то администратором, это изменяется вручную в базе данных или через отдельную админ-панель. Важно не доверять ролям, которые могут прийти от провайдера: Google не знает, кто должен быть админом в твоём приложении.

Это ещё один аргумент в пользу использования реляционной базы вместе с OAuth. В таблице пользователей можно хранить role, createdAt, provider, providerAccountId и другие поля, нужные именно твоему приложению.

Частые вопросы

Может ли приложение узнать пароль пользователя от Google через OAuth?

Нет. Пароль вводится только на сайте провайдера. Твоё приложение получает токен и разрешённые данные — обычно email, имя и уникальный идентификатор. Пароль остаётся у провайдера.

Обязательно ли использовать OAuth для входа?

Нет. Это один из вариантов. Можно сделать классическую регистрацию по email и паролю, вход по коду из SMS или email, или использовать другие провайдеры. OAuth просто делает вход быстрее и безопаснее для пользователя.

Что делать, если Google заблокирован у части пользователей?

Предусмотри альтернативные способы входа. Например, можно добавить вход через GitHub, Yandex или российские провайдеры вроде «Сбер ID». Также полезно иметь классический вход по email для тех, кто не хочет привязывать сторонний аккаунт.

Что такое Client ID и Client Secret?

Это два ключа, которые провайдер выдаёт твоему приложению при регистрации. Client ID идентифицирует приложение и может быть виден в коде. Client Secret — секретный ключ, который используется на сервере для обмена кода на токен. Его нельзя показывать пользователям.

Нужно ли платить за OAuth?

Сам протокол OAuth бесплатный. Провайдеры вроде Google, GitHub, Yandex не берут деньги за базовый вход в приложение. Но могут быть лимиты на количество пользователей или запросов, поэтому актуальные условия лучше смотреть на сайте провайдера.

Что произойдёт, если пользователь удалит свой Google-аккаунт?

Если OAuth был единственным способом входа, пользователь потеряет доступ к твоему приложению. Чтобы снизить риск, можно позволить привязывать несколько провайдеров к одному аккаунту или добавить резервный вход по email.

Какие данные можно получить через OAuth?

Это зависит от запрошенных scope. Для входа обычно достаточно email и имени. Если запросить дополнительные разрешения, можно получить доступ к календарю, файлам, контактам и другим данным — но пользователь должен явно на это согласиться.