WIKI / ПРОТОКОЛЫ

OIDC и OAuth 2.0

Базовая модель доверия между приложением, браузером, identity-сервером и API.

RustCloak / Технические материалы · Сверяйте примеры с используемой версией проекта.

Что решает каждый протокол

OAuth 2.0 описывает делегирование авторизации. OpenID Connect добавляет поверх OAuth 2.0 уровень аутентификации — идентичность пользователя и ID token.

Authorization Code Flow с PKCE

  1. Приложение создаёт state, а для OIDC — nonce; формирует code_verifier и code_challenge.
  2. Браузер переходит на endpoint авторизации.
  3. Сервер проверяет клиента, redirect URI и выполняет сценарий входа.
  4. Браузер возвращается в приложение с краткоживущим authorization code.
  5. Приложение обменивает код и code_verifier на токены через token endpoint.
  6. Приложение и API проверяют предназначенные им токены по issuer, audience, подписи и срокам действия.
Приложение→Браузер→RustCloak→Redirect + code→Token endpoint

Endpoint discovery

OIDC discovery предоставляет клиенту адреса авторизации, токенов, JWKS и другие параметры. Полный путь discovery зависит от реализации и конфигурации issuer: не подставляйте шаблонные URL, пока их не подтвердили интеграционными тестами.

Что нельзя пропускать

  • Точное совпадение разрешённого redirect URI.
  • Проверка state, nonce и PKCE.
  • Проверка iss, aud, exp и подписи токена.
  • Корректная обработка ошибок и отсутствие утечки токенов в URL, логи и analytics.

Полезно различать контроль над локальной сессией приложения и сроком действия выпущенных токенов. Их жизненные циклы не совпадают.

Как это связано с RustCloak

Протокольный слой отвечает за OIDC/REST-сценарии; точный набор endpoints и совместимость клиентов должны быть подтверждены тестами выбранного commit. См. API и интеграции.