Замена коды для маркеров в OpenID Connect коды авторизации потоке

Question

В OpenID Connect Basic Client Implementer's Guide претензиях в разделе 2.1.6.1, что клиент должен отправить запрос на POST/token маршрут поставщика удостоверений для обмена кода авторизации для маркеров.

Образец показано, выглядит следующим образом:

POST /token HTTP/1.1 
Host: server.example.com 
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
Content-Type: application/x-www-form-urlencoded 

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 

Я прекрасно понимаю, почему один должен предоставить параметр grant_type, и я также понимаю, почему вы должны предоставить code.

Но я смотрю на раздел 2.1.6.2 ответ не дается с помощью редиректа, но, отправив простой 200 ответ с JSON-закодирован тела:

HTTP/1.1 200 OK 
Content-Type: application/json 
Cache-Control: no-cache, no-store 
Pragma: no-cache 

{ 
    "access_token":"SlAV32hkKG", 
    "token_type":"Bearer", 
    "expires_in":3600, 
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", 
    "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" 
} 

Нет, я задаюсь вопросом, если ответ это не с использованием перенаправления, но напрямую отправляется клиенту, то почему в вышеуказанном запросе содержится параметр redirect_uri?

Это ошибка копирования/вставка из раздела 2.1.2, где первоначально запрашивается код авторизации, или я что-то не хватает?

Answer 1

Нет. Интересно, если ответ не задан с использованием перенаправления, а напрямую отправляется клиенту, то почему в вышеуказанном запросе содержится параметр redirect_uri?

Отправка redirect_uri к лексем конечной на самом деле функция безопасности, хорошо объясняется в OAuth 2.0 Authorization Framework specification:

При запросе авторизации с использованием типа гранта кода авторизации, клиент может указать перенаправление URI через Параметр «redirect_uri». Если злоумышленник может манипулировать значением URI перенаправления, он может заставить сервер авторизации перенаправить пользователя-агента владельца ресурса в URI под управлением злоумышленника с кодом авторизации.

Злоумышленник может создать учетную запись у законного клиента и инициировать поток авторизации. Когда пользовательский агент злоумышленника отправляется на сервер авторизации для предоставления доступа, злоумышленник захватывает URI авторизации, предоставляемый законным клиентом, и заменяет URI перенаправления клиента URI под контролем злоумышленника. Затем злоумышленник обманывает жертву, следуя манипулируемой ссылке, чтобы разрешить доступ к законному клиенту.

После того, как на сервере авторизации жертве будет предложен нормальный, действительный запрос от имени законного и доверенного клиента и авторизует запрос. Затем жертва перенаправляется на конечную точку, находящуюся под контролем злоумышленника, с кодом авторизации. Атакующий завершает поток авторизации, отправив код авторизации клиенту, используя исходный URI перенаправления, предоставленный клиентом. Клиент обменивает код авторизации с токеном доступа и связывает его с учетной записью клиента злоумышленника, которая теперь может получить доступ к защищенным ресурсам, разрешенным жертвой (через клиента).

Чтобы предотвратить такую ​​атаку, сервер авторизации ДОЛЖЕН обеспечить, чтобы URI перенаправления, используемый для получения кода авторизации, был идентичен URI перенаправления при обмене кода авторизации для токена доступа.Сервер авторизации ДОЛЖЕН требовать публичных клиентов и ДОЛЖЕН требовать от конфиденциальных клиентов регистрировать свои URI перенаправления. Если в запросе указан URI перенаправления, сервер авторизации ДОЛЖЕН подтвердить его по отношению к зарегистрированному значению.

Он также упоминается в OAuth 2.0 Threat Model and Security Considerations RFC:

сервер авторизации должен быть в состоянии связать все разрешения «код» для фактического перенаправления URI, используемого в качестве цели перенаправления клиента в конечном пользователе авторизации. Эта привязка должна быть проверена, когда клиент пытается обменять соответствующий «код» авторизации для токена доступа. Эта мера является контрмерой против утечки «кода» через поддельные веб-сайты, поскольку злоумышленник не может использовать другой URI переадресации для обмена «кодом» авторизации в токен.