OAuth
OAuth 2.0 — протокол делегирования доступа: приложение получает ограниченный доступ к вашим данным в другом сервисе, не узнавая ваш пароль.
Что такое OAuth
OAuth (Open Authorization) — открытый протокол делегирования доступа. Актуальная версия — OAuth 2.0, стандарт RFC 6749; «oauth2» и «oauth 2.0» означают его же. Версия 1.0 несовместима с ней и практически вымерла.
Задача, которую решает OAuth, формулируется так: дать приложению ограниченный доступ к вашим данным в другом сервисе, не отдавая ему пароль. До OAuth сервису, который хотел прочитать вашу почту, приходилось просить логин и пароль от почты — то есть получать полный и вечный доступ ко всему аккаунту.
OAuth заменяет это на: «выдать вот этому приложению право читать список файлов, на час, с возможностью отозвать в любой момент». Пароль знает только сам сервис, приложение получает токен.
Самое частое заблуждение: OAuth — это протокол авторизации, а не аутентификации. Он отвечает «этому приложению разрешено делать X», а не «это Иванов». Access-токен ничего не говорит о личности владельца — он говорит о правах. Строить вход на чистом OAuth 2.0 — известный источник уязвимостей; для входа существует OIDC (OpenID Connect) — надстройка над OAuth, которая добавляет id_token в формате JWT с данными о пользователе. Кнопка «Войти через Google» — это OIDC, а не голый OAuth.
Роли
- Resource Owner — пользователь, владелец данных.
- Client — приложение, которое просит доступ.
- Authorization Server — выдаёт токены, спрашивает согласие. Обычно это IdP.
- Resource Server — API с данными, принимает токен.
Authorization Code Flow
Основной сценарий, и единственный правильный для веб- и мобильных приложений:
1. User → Client: хочу подключить Google Drive
2. Client → Browser: редирект на accounts.google.com
?client_id=...&redirect_uri=...&scope=drive.readonly
&code_challenge=...&state=xyz
3. Auth Server: вход + экран согласия «Приложение X хочет читать файлы»
4. Auth Server → Browser: редирект на redirect_uri?code=ABC&state=xyz
5. Client → Auth Server: POST /token — code + client_secret + code_verifier
6. Auth Server → Client: { access_token, refresh_token, expires_in }
7. Client → API: Authorization: Bearer <access_token>
Почему так сложно: через браузер летит только одноразовый code, а обмен на токен идёт по бэкенд-каналу. Токен никогда не появляется в адресной строке, в истории браузера и в логах прокси.
PKCE (RFC 7636, «пикси») — обязательное расширение. Клиент генерирует случайный code_verifier, шлёт его хеш в первом запросе и сам верификатор при обмене. Это защищает от перехвата кода: даже украв code, атакующий не обменяет его на токен. Изначально PKCE придумали для мобильных приложений, но в OAuth 2.1 он становится обязательным для всех, включая веб.
Типы grant
| Grant | Для кого | Статус |
|---|---|---|
| Authorization Code + PKCE | Веб, мобильные, SPA | Рекомендованный |
| Client Credentials | Сервис-сервис, без пользователя | Актуален |
| Device Code | ТВ, консоли, CLI | Актуален |
| Refresh Token | Обновление access-токена | Актуален |
| Implicit | SPA (исторически) | Устарел, не использовать |
| Resource Owner Password | Прямая передача логина и пароля | Устарел, противоречит смыслу OAuth |
Client Credentials — то, что нужно для интеграций между вашими сервисами: пользователя нет, приложение аутентифицируется своими учётными данными и получает токен. Именно этот grant используют скрипты и CI/CD.
Scopes и практика
Scope — область запрашиваемых прав (drive.readonly, user:email). Именно scopes показываются на экране согласия и определяют, что можно делать с токеном. Правило — запрашивать минимум: приложение, просящее полный доступ к диску ради загрузки аватарки, обоснованно вызывает подозрения.
Что важно на практике:
redirect_uriсверяется точно, по полному совпадению из белого списка. Открытый редирект — классический способ увести код.- Параметр
stateобязателен: он защищает от CSRF и связывает ответ с исходным запросом. - Короткий
expу access-токена, отзыв — через refresh (см. JWT). client_secret— только на бэкенде. В SPA и мобильном приложении секрета быть не может: его извлекут из бандла. Для них — PKCE вместо секрета.- Только поверх TLS. Bearer-токен не привязан к отправителю: кто перехватил — тот и владелец.
Поднять свой authorization server проще всего на Keycloak — он умеет и OAuth 2.0, и OIDC, и SAML.
Связанные термины
- JWT и токены — формат того, что выдаёт OAuth
- SSO — единый вход, построенный на OIDC поверх OAuth
- IAM / IdP — где живёт authorization server
- Аутентификация — то, чем OAuth сам по себе не является
- API-ключи — более простая альтернатива для машинных интеграций
Готовы запустить GPU-задачу?
Запустить GPU-сервер