Средний ~30 мин чтения

OAuth 2.0 и OpenID Connect

Урок 4 из 6 в курсе Аутентификация и авторизация

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегирования доступа; OpenID Connect добавляет идентификацию поверх OAuth, обеспечивая 'Войти через Google'

Почему это важно: OAuth 2.0 — стандарт для интеграций (API третьих сторон, social login). Неправильная реализация ведёт к account takeover

Главная идея

OAuth не передаёт пароль третьей стороне; вместо этого сервер авторизации выдаёт ограниченный access token по согласию пользователя

Как это выглядит на практике

  1. Пользователь нажимает 'Войти через Google'.
  2. Приложение перенаправляет на Google с client_id, redirect_uri, scope, state (CSRF-защита).
  3. Google просит пользователя дать согласие на доступ к email и профилю.
  4. Google перенаправляет обратно с code; приложение меняет code на access_token и id_token.
  5. ID token (OpenID Connect) содержит user_id, email; приложение создаёт или находит пользователя.

Что происходит под капотом

  • Authorization Code Flow + PKCE (Proof Key for Code Exchange) — стандарт для web и мобильных приложений.
  • code_verifier и code_challenge: защита от перехвата authorization code в мобильных приложениях.
  • Client Credentials Flow — для machine-to-machine; нет пользователя, только client_id + secret.
  • Token introspection: сервер ресурсов проверяет access token у authorization server.
  • Scopes: openid (идентификация), profile, email, read:posts — гранулярные разрешения.

Типичные ошибки и заблуждения

  • Ошибка: OAuth 2.0 — протокол аутентификации. OAuth — делегирование авторизации. Аутентификацию добавляет OpenID Connect.
  • Ошибка: state параметр необязателен. state — защита от CSRF; его отсутствие — уязвимость.
  • Ошибка: access token можно хранить вечно. Access token имеет TTL; после истечения нужен refresh token.
  • Ошибка: implicit flow актуален. Implicit flow устарел и небезопасен; используйте Authorization Code + PKCE.

Ключевые выводы

  • OAuth 2.0 = делегирование доступа без передачи пароля.
  • OpenID Connect = OAuth 2.0 + id_token для аутентификации.
  • state параметр обязателен для защиты от CSRF.
  • Authorization Code + PKCE — стандартный flow для всех клиентских приложений.

Термины урока

OAuth 2.0: протокол делегирования доступа к ресурсам.
Authorization Server: сервер, выдающий токены (Google, GitHub, Auth0).
Access Token: токен доступа к API от имени пользователя.
OpenID Connect: надстройка над OAuth 2.0 для идентификации; добавляет id_token.
PKCE: расширение для защиты authorization code flow в публичных клиентах.
Scope: набор разрешений, запрашиваемых приложением у пользователя.

Связь с работой backend-разработчика

Для social login используйте готовые библиотеки (Devise OmniAuth, Passport.js, Spring Security OAuth). Реализация OAuth с нуля полна подводных камней. Всегда проверяйте state, используйте PKCE.

Мини-разбор реальной ситуации

Приложение реализует 'Войти через GitHub' без проверки state параметра. Атака CSRF: злоумышленник начинает OAuth flow, получает authorization code, подменяет его — жертва логинится под аккаунтом злоумышленника. Одна строка проверки state предотвращает account takeover.

Что запомнить

  • OAuth = доступ, OpenID Connect = идентификация.
  • Всегда проверяй state параметр.
  • Используй Authorization Code + PKCE, не Implicit flow.

Итог

OAuth 2.0 и OpenID Connect — сложные протоколы. Используйте проверенные библиотеки и читайте спецификацию перед нестандартными реализациями.