WinFormsSample с клиентом native.hybrid больше не работает?

Question

Если я изменю клиента в этом примере на "native.hybrid" https://github.com/IdentityModel/IdentityModel.OidcClient.Samples/tree/master/WinFormsWebView

и установите Flow = OidcClientOptions.AuthenticationFlow.Hybrid

тогда вход в IS4 работает (после задержки в 5 секунд), но в моем браузере по умолчанию появляется новая форма входа.

С клиентом Interactive.public работает нормально. У меня вопрос: какой поток я должен использовать для моего родного приложения для вдов? Я имею в виду, что это "Гибридный поток OpenID Connect", см. https://identityserver4.readthedocs.io/en/latest/topics/grant_types.html

Если использовать гибридный поток, как можно адаптировать этот образец?

Answer 1

Текущее практическое правило выбора гранта для использования с OIDC:

• Связь между компьютером: используйте ClientCredentials.

• Интерактивный клиент (веб-приложения, SPA или собственные / мобильные приложения): используйте код + PKCE

---

ClientCredentials: этот поток состоит из одного запроса к конечной точке токена, предоставляя client_id и client_secret (например, пользователя / пароль) для аутентификации против полномочий.

---

Код +PKCE: этот поток состоит из двух запросов:

1. Запрос на авторизацию конечной точки, который будет выполнен во Front-Channel, в любом случае с использованием веб-браузера, и ответит (в случае успеха) перенаправлением на предоставленный redirect_uri(предварительно настроил на сервере). В этом перенаправлении орган власти добавит "код" среди других параметров как "фрагмент" или "запрос" (example.com/signin#code=1234).

2. Запрос к конечной точке токена, предоставляющий полученный код, который ответит фактическим запрошенным токеном.

Проблема здесь в том, как аутентифицировать клиента, выполняющего второй запрос. В гибридном потоке мы используем секрет, как и в случае с учетными данными клиента, проблема в том, что не все приложения могут безопасно хранить этот секрет (то есть: SPA загружает весь свой код в клиентском браузере, поэтому секрет будет там, чтобы любой мог его украсть.) (поэтому мы делаем различие между конфиденциальными (способными хранить секреты в безопасности) и общедоступными клиентами).

Здесь пригодится PKCE: он повышает безопасность этого потока, добавляя дополнительную проверку:

1. В первом запросе на авторизацию клиент предварительно создает случайную строку asdfasdf и вычисляет ее хэш. Этот хеш добавляется к запросу вместе с алгоритмом, используемым для его вычисления, например: SHA256.

2. Во втором запросе клиент включает строку в виде простого текста "asdfasdf", таким образом орган может вычислить хэш этой строки и проверить, совпадает ли он с предоставленным в первом запросе. Если это так, то мы можем сделать вывод, что клиент, отправивший второй запрос, совпадает с тем, который сделал первый запрос. Учитывая, что первый запрос заканчивается на ранее настроенномredirect_uri только авторизованный клиент может завершить поток.