Security

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 ServerAPI с данными, принимает токен.

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-сервер