OAuth 2.0 Код авторизации Грант без секретности

Question

Итак, я рассматривал настройку OAuth 2.0 для мобильного приложения Cordova с использованием Microsoft cordova-plugin-ms-adal plugin (который использует собственные библиотеки) против пользовательского API с использованием Azure AD. Все это хорошо работает, но я немного запутался в использовании тайны (или, точнее, ее отсутствия).

Во многих статьях в Интернете говорится, что при использовании гранта авторизационного кода и запроса маркера вы включаете секрет. И этот тип гранта идеально подходит для использования, когда вы можете безопасно хранить секрет, например. на сервере.

Однако плагин не требует, чтобы в приложении был указан секрет, но он по-прежнему использует грант авторизационного кода для аутентификации. Также можно вручную вызвать

https://login.windows.net/common/oauth2/authorize?resource=http://***.onmicrosoft.com/***API&client_id=***&response_type=code&redirect_uri=http://***.onmicrosoft.com/***App 

в моем браузере, Логин, получить код и затем POST к https://login.windows.net/common/oauth2/token с

grant_type: authorization_code 
client_id: *** 
code: *** 
redirect_uri: http://***.onmicrosoft.com/***App 
resource: http://***.onmicrosoft.com/***API 

и это работает, так что я получаю обратно действительный JWT, без отправьте секрет.

Почему ?? Это менее безопасно? (Я также заметил, что OAuth 2.0 spec section 4.1.3 не утверждает, что секрет требуется для типа гранта кода авторизации !?)

Каковы последствия использования типа грантовый authorization_code без секретного основного заголовка/Идента?

Answer 1

Смысл использования grant_type=authorization_code (или любой другой поток) с общественным клиентом (тот, который не имеет секрет или аутентифицировать каким-либо иным способом) является то, что маркер доступа предоставляется не представляет авторизацию клиента к ресурсу он представляет только авторизацию пользователя ресурсу.

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

Answer 2

В ссылке, которую вы разместили запрос включает в себя также (возможно, вы этого не заметили):

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

Поэтому client_secret не было действительно необходимо.

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

If the client type is confidential or the client was issued client 
credentials (or assigned other authentication requirements), the 
client MUST authenticate with the authorization server as described 
in Section 3.2.1. 

Answer 3

Используя грант кода авторизации с помощью так называемого конфиденциального клиента (клиент, который имеет клиентский секрет) более безопасен, чем использование общедоступного Клиента.

Это связано с тем, что обмен кодом авторизации происходит как параметр URL-адреса в переднем канале, то есть через браузер, и, как таковой, относительно уязвим для таких атак, как кросс-скриптинг, клик-манипуляция, манипуляция сетью/DNS и т. Д. Это означает, что выделенный специалист может украсть код авторизации у пользователя при определенных обстоятельствах (неаккуратный пользователь, сетевое управление злоумышленником, небрежное перенаправление URI в реализации сервера и т. Д.).

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

Это означает, что относительно легко злоумышленник имитировать публичную клиенту, так как это требует только без секретной информации (он может захватить client_id и redirect_uri из своего браузера) и разрешение code, что он может хватайтесь за атаку, как описано выше.

Хотя захват кода авторизации для конфиденциального клиента работает так же, злоумышленник не может использовать его и обменивать его на токен доступа, потому что для этого ему нужен секрет клиента, который обычно намного сложнее получить для злоумышленник. Секрет обычно хранится на сервере в бэкэнд-памяти и передается только по защищенному каналу HTTP, поэтому он не течет.