OAuth 2.0 — открытый стандарт делегированной авторизации (RFC 6749, 2012). Позволяет приложению получить ограниченный доступ к ресурсам пользователя на другом сервисе без знания его пароля. Пользователь явно разрешает доступ, после чего приложение получает access token с конкретным набором прав (scope) и сроком действия.
Четыре роли в OAuth 2.0
- Resource Owner (владелец ресурса)
- Пользователь, чьи данные запрашивает приложение.
- Client (клиент)
- Приложение, запрашивающее доступ к ресурсам.
- Authorization Server (сервер авторизации)
- Выдаёт access token после получения согласия пользователя. Например, accounts.google.com.
- Resource Server (сервер ресурсов)
- Хранит данные пользователя. Принимает запросы с access token. Например, gmail.googleapis.com.
Authorization Code Flow (основной поток)
- Приложение перенаправляет пользователя на authorization server с параметрами: client_id, scope, redirect_uri, state.
- Пользователь входит в аккаунт и разрешает доступ.
- Authorization server перенаправляет обратно с одноразовым authorization code.
- Приложение обменивает code на access token (server-to-server запрос, не через браузер).
- Access token используется для запросов к Resource Server.
Для мобильных приложений и SPA используют расширение PKCE (Proof Key for Code Exchange, RFC 7636) — защита от перехвата authorization code.
Другие grant types
| Flow | Для кого | Когда использовать |
|---|---|---|
| Authorization Code + PKCE | Web-приложения, мобильные, SPA | Стандартный выбор |
| Client Credentials | M2M (сервис ↔ сервис) | Нет пользователя, только машины |
| Device Code | TV, IoT, CLI | Устройства без браузера |
| Implicit (устарел) | Старые SPA | Не использовать в новых проектах |
История
OAuth 1.0 появился в 2007 году как попытка стандартизировать авторизацию между Twitter, Ma.gnolia и другими сервисами. Версия 1.0 требовала сложной криптографической подписи каждого запроса. OAuth 2.0 (RFC 6749) опубликован IETF в октябре 2012 года — полностью переработан с упрощённой архитектурой, поддержкой мобильных приложений и токенами Bearer. OAuth 1.0 официально устарел. Сегодня OAuth 2.0 используют практически все крупные платформы: Google, GitHub, Microsoft, Facebook, Yandex.
OAuth 2.0 vs OpenID Connect
OAuth 2.0 — только про авторизацию (доступ к ресурсам). OpenID Connect (OIDC) — надстройка над OAuth 2.0 для аутентификации (кто этот пользователь). OIDC добавляет ID token (JWT) и эндпоинт /userinfo. Когда нужна кнопка «Войти через Google» — это OIDC поверх OAuth 2.0.
OAuth 2.0: безопасность реализации
Частые ошибки при реализации OAuth 2.0: использование Implicit Flow для новых проектов (устарел, уязвим к token leakage через referrer), отсутствие валидации redirect_uri (open redirect), хранение access token в localStorage (доступен XSS). Безопасная реализация: Authorization Code + PKCE, secure HTTPOnly cookie для refresh token, in-memory storage для access token.
Token introspection (RFC 7662): Resource Server проверяет валидность token через POST /introspect вместо JWT-верификации — нужно для opaque (не JWT) токенов. Revocation endpoint (RFC 7009): POST /revoke для аннулирования refresh token при logout. JWT access tokens: Resource Server верифицирует подпись по public key без обращения к Authorization Server — снижает latency и нагрузку. JWK Set endpoint (.well-known/jwks.json) публикует публичные ключи для верификации JWT.
На что обращать внимание
Access token — это секрет: передавай только через HTTPS, не логируй, не передавай в URL-параметрах. Время жизни access token — обычно 1 час. Для длительного доступа используется refresh token. Параметр state в authorization request — обязательная защита от CSRF-атак. При реализации API проверяй scope токена перед выдачей данных через API.