oauth 20

OAuth 2.0 — открытый протокол авторизации, позволяющий приложениям получать ограниченный доступ к ресурсам пользователя в сторонних сервисах без передачи логина и пароля. Стандарт описан в RFC 6749 и является основой для кнопок «Войти через Google / GitHub / Яндекс» и для делегированного доступа между API. OAuth 2.0 решает задачу авторизации (что можно делать), тогда как OpenID Connect, построенный поверх него, решает задачу аутентификации (кто пользователь).

Роли в OAuth 2.0

Протокол определяет четыре участника:

• Resource Owner (владелец ресурса) — пользователь, которому принадлежат данные (например, его Google-контакты).
• Resource Server (сервер ресурсов) — API, хранящее данные пользователя (Google Contacts API).
• Client (клиент) — приложение, запрашивающее доступ к данным от имени пользователя (ваш сайт или мобильное приложение).
• Authorization Server (сервер авторизации) — выдаёт токены доступа после подтверждения пользователем. Часто совмещён с сервером ресурсов (Google OAuth Server).

Ключевые типы потоков (Grant Types)

OAuth 2.0 определяет несколько потоков для разных сценариев:

• Authorization Code — основной и наиболее безопасный поток для веб-приложений. Клиент получает authorization code (через браузер пользователя), затем обменивает его на access token через прямой server-to-server запрос. Для публичных клиентов (SPA, мобильные приложения) дополняется PKCE.
• Authorization Code + PKCE (Proof Key for Code Exchange) — расширение для публичных клиентов, где нельзя хранить секрет. Клиент генерирует случайный code_verifier, хэширует его в code_challenge и отправляет при запросе кода. При обмене кода на токен передаёт code_verifier — сервер проверяет соответствие.
• Client Credentials — для machine-to-machine взаимодействия без участия пользователя. Клиент аутентифицируется своим ID и секретом и получает токен. Используется в микросервисах.
• Refresh Token — не самостоятельный поток, а механизм обновления истёкшего access token без повторной авторизации пользователя.

Устаревшие потоки (Implicit, Resource Owner Password Credentials) не рекомендуются к использованию в новых проектах.

Authorization Code Flow: пошаговый разбор

1. Пользователь нажимает «Войти через Google» на вашем сайте.
2. Сайт перенаправляет браузер на Google Authorization Server с параметрами: client_id, redirect_uri, scope, response_type=code, state (CSRF-защита).
3. Google показывает страницу согласия (consent screen) с перечнем запрашиваемых разрешений.
4. Пользователь соглашается. Google перенаправляет обратно на redirect_uri с параметром code.
5. Сервер вашего сайта отправляет POST-запрос к Google Token Endpoint с code, client_id и client_secret.
6. Google возвращает access_token, refresh_token и (если запрошен OpenID Connect) id_token.
7. Сервер использует access_token для обращения к Google API от имени пользователя.

Scopes: ограничение доступа

Scopes определяют, к каким ресурсам и действиям клиент запрашивает доступ. Пользователь видит запрашиваемые разрешения на странице согласия и может отозвать их позже. Примеры scopes Google: profile, email, https://www.googleapis.com/auth/calendar.readonly. Принцип минимальных привилегий: запрашивать только те scopes, которые действительно нужны приложению.

Access Token и его хранение

Access token — краткоживущий токен (минуты/часы) для доступа к API. Обычно это JWT (в OpenID Connect) или непрозрачная строка (opaque token). В браузерных приложениях хранится в памяти или httpOnly cookie. В мобильных приложениях — в защищённом хранилище (Keychain на iOS, Keystore на Android). Никогда не следует хранить access token в незащищённом хранилище.

OpenID Connect поверх OAuth 2.0

OAuth 2.0 решает авторизацию: «дать приложению доступ к ресурсу». OpenID Connect (OIDC) добавляет аутентификацию: «подтвердить личность пользователя». OIDC вводит ID Token (JWT с данными о пользователе), UserInfo Endpoint и стандартный набор scopes (openid, profile, email). Практически все системы «Войти через...» используют OIDC, а не чистый OAuth 2.0.

Практика: реализация OAuth в приложении

Использование готовых библиотек вместо реализации вручную — правило безопасности. Для Next.js: NextAuth.js (Auth.js), Lucia. Для Node.js: Passport.js, openid-client. Для Python: Authlib, python-jose. Сервисы авторизации (Auth0, Clerk, Okta, Supabase Auth, Keycloak) предоставляют полное решение, избавляя от необходимости управлять ключами, refresh token-ами и безопасностью самостоятельно.