Как работают OAuth 2.0 и OpenID Connect

Коротко

OAuth 2.0 — это протокол авторизации: он отвечает на вопрос «что приложению разрешено делать от имени пользователя». Пользователь не отдаёт приложению свой пароль, а приложение получает access token с ограниченными правами.

OpenID Connect (OIDC) — надстройка над OAuth 2.0 для аутентификации: она отвечает на вопрос «кто этот пользователь». Для этого OIDC добавляет ID token — подписанный документ с данными о входе.

Кнопка «Войти через Google» — это почти всегда OIDC.

Четыре роли

• Resource owner — пользователь, которому принадлежат данные.
• Client — ваше приложение: сайт, мобильное приложение, бот.
• Authorization server — сервер, который проверяет пользователя и выдаёт токены (например, Google).
• Resource server — API, к которому нужен доступ (например, Google Calendar API).

Иногда authorization server и resource server принадлежат одной компании, но логически это разные роли.

Authorization code flow с PKCE

Это основной и рекомендуемый сценарий для сайтов, SPA и мобильных приложений. PKCE (Proof Key for Code Exchange) защищает от перехвата кода авторизации.

1. Приложение генерирует случайную строку code_verifier и считает от неё code_challenge — SHA-256 в base64url.
2. Пользователя перенаправляют на authorization server с параметрами: client_id, redirect_uri, scope, state и code_challenge.
3. Пользователь входит и соглашается выдать доступ.
4. Сервер возвращает пользователя на redirect_uri с одноразовым кодом и тем же state.
5. Приложение отправляет код вместе с code_verifier на token endpoint.
6. Сервер проверяет, что verifier соответствует challenge, и выдаёт токены.

GET /authorize?response_type=code
  &client_id=my-app
  &redirect_uri=https://app.example.com/callback
  &scope=openid%20email%20profile
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

Даже если злоумышленник перехватит код на шаге 4, без code_verifier он не обменяет его на токены. Параметр state защищает от подмены ответа (CSRF): приложение сверяет его с тем, что сохранило перед редиректом.

Старый implicit flow, где токен приходил прямо в адресной строке, больше не рекомендуется — используйте code flow с PKCE.

Access token и ID token

Главное правило: не используйте access token как доказательство входа, а ID token — как пропуск к API. Это разные документы для разных получателей.

Ещё бывает refresh token — долгоживущий токен для получения новых access-токенов без повторного входа. Храните его только на сервере или в защищённом хранилище устройства.

Scopes

Scope — это запрошенное право. В OIDC обязателен scope openid, к нему обычно добавляют email и profile. Для доступа к API запрашивают отдельные scopes, например на чтение календаря.

Запрашивайте минимум: чем шире список, тем больше пользователей откажутся на экране согласия и тем больше ущерб при утечке токена.

Пример: вход через Google

1. Вы регистрируете приложение в консоли Google и получаете client_id, указываете разрешённые redirect_uri.
2. Кнопка «Войти через Google» отправляет пользователя на страницу Google со scope openid email profile.
3. После входа Google возвращает код, ваш сервер меняет его на ID token и access token.
4. Вы проверяете ID token и берёте из него sub — постоянный идентификатор пользователя у Google — и email.
5. По sub находите или создаёте пользователя в своей базе и открываете обычную сессию.

Если приложению нужен ещё и календарь, вы добавляете соответствующий scope — это уже авторизация через OAuth, а не просто вход.

Частые ошибки

• Идентифицировать пользователя по email вместо sub: email может смениться.
• Не проверять подпись и aud у ID token.
• Хранить client_secret в мобильном приложении или во фронтенде.
• Разрешать произвольные redirect_uri или wildcard-адреса.
• Писать протокол с нуля вместо проверенной библиотеки.