OAuth2 Flow: причина отправки кода авторизации через редирект

Question

Почему сервер авторизации отправляет код авторизации в виде перенаправления через пользовательский агент (браузер), а не напрямую на URI обратного вызова клиента?

В наиболее безопасном потоке: из-за многочисленных потенциальных векторов атак токены доступа не отправляются клиентскому бэкэнду через перенаправление через браузер агента пользователя. Это указано в 3.4. из OAuth 2.0 Threat Model and Security Considerations. Таким образом, перенаправление через браузер делает короткий код аутентификации выгодным.

Но давайте предположим, что сервер авторизации установил прямой канал связи с клиентом через некоторый ранее указанный URI. Может ли сервер не просто немедленно отправить токен доступа и, таким образом, упростить поток?

Answer 1

Браузер перешел к клиентскому приложению, был перенаправлен на сервер авторизации, который выполнил аутентификацию пользователя и выдал код. Если сервер авторизации будет вызывать клиентское приложение через обратный канал (прямой сервер-серверный вызов), чтобы передать код клиентскому приложению, ему все равно потребуется перенаправить браузер обратно в клиентское приложение после завершения.

Что бы сделал браузер, чтобы связать себя с выданным кодом? Как клиентское приложение узнает, что входящий HTTP-запрос относится к выданному коду?

Использование параметра состояния, сгенерированного клиентом, для этого намного рискованнее, чем код, созданный сервером авторизации (время жизни второго из них значительно меньше).

Кроме того, не все серверы авторизации могут отправлять исходящие запросы.