Для чего этот поток

2.0 (RFC 6749) позволяет приложению действовать от имени пользователя, ни разу не видя пароля пользователя. «Войти через Google» — повседневный пример: приложение получает разрешение на доступ к чему-либо, но именно Google, а не приложение, обрабатывает учётные данные. Поток кода авторизации — самый распространённый и самый безопасный способ это устроить, и это поток, который защищает .

Четыре роли

  • Владелец ресурса (resource owner) — это пользователь, который владеет данными и предоставляет доступ.
  • Клиент (client) — это приложение, запрашивающее доступ.
  • Сервер авторизации (authorization server) аутентифицирует пользователя и выпускает токены (Google, провайдер идентичности, ваш собственный сервис аутентификации).
  • Сервер ресурсов (resource server) — это API, который держит защищённые данные и принимает токен.

Танец, шаг за шагом

  1. Редирект для авторизации. Клиент отправляет браузер пользователя на эндпоинт авторизации сервера авторизации, неся свой client_id, redirect_uri, желаемый scope, случайное значение state и (с PKCE) challenge кода. Клиент никогда не обрабатывает пароль.
  2. Аутентификация и согласие. Сервер авторизации входит за пользователя и просит его одобрить запрошенные области.
  3. Редирект обратно с кодом. Сервер перенаправляет браузер обратно на redirect_uri клиента с короткоживущим кодом авторизации и исходным state. Клиент проверяет, что state совпадает, что защищает от межсайтовой подделки запроса при обратном вызове.
  4. Обмен кода на токены. Теперь по тыловому каналу (прямой вызов сервер-серверу, не браузер) клиент отправляет код на эндпоинт токена вместе со своими учётными данными (секрет клиента или verifier кода PKCE) и получает токен доступа, часто токен обновления, а для OpenID Connect — ID-токен.
  5. Вызов API. Клиент предъявляет токен доступа серверу ресурсов, который его проверяет и возвращает данные.

Почему код, а не токен напрямую?

Обходной путь через код авторизации существует, чтобы токен никогда не путешествовал через адресную строку или историю браузера, где он мог бы утечь. Код, который действительно путешествует там, бесполезен сам по себе: его погашение требует вызова по тыловому каналу с секретом клиента или verifier PKCE. Это разделение, одноразовый код на фронтальном канале и настоящий токен на тыловом канале, — центральное свойство безопасности потока.

Это также ровно та брешь, которую PKCE заполняет для клиентов, не способных хранить секрет (одностраничные и мобильные приложения): он привязывает код к одноразовому verifier, так что перехваченный код всё равно нельзя обменять. Токены, которые возвращает поток, очень часто являются .

Инструмент PKCE генерирует и проверяет verifier и challenge, на которые опирается этот поток, а инструмент JWT декодирует токены, которые он возвращает, оба локально в вашем браузере.