Identity Server 4 с WebAuthN - с использованием GrantType (FIDO 2.0)

Я использую Identity Server 4 для аутентификации пользователей с помощью WebAuthN (https://w3c.github.io/webauthn/).

У меня есть несколько клиентов, которые попадают в клиент api. Мой клиент api отвечает за решение, какой поставщик аутентификации использовать, передачу данных (сервер на сервер, сервер на внешний API) и организацию процесса аутентификации.

Один из используемых нами провайдеров аутентификации - это сервер идентификации 4, и именно здесь мы реализуем WebAuthN.

Я не уверен, что это рекомендуемый способ реализовать это в Identity Server 4. У меня есть 2 варианта.

  1. Создайте конечную точку API на сервере идентификации для аутентификации учетных данных пользователей.
  2. Создайте тип предоставления расширения и вызовите API TokenEndpoint, используя новый тип предоставления (мой тип предоставления расширения будет представлять собой смесь встроенного гибридного типа предоставления, за которым следует код WebAuthN).

Оба способа действительны с точки зрения безопасности (не открывают дыру) и подходят для ID4, или есть другой способ?


identityserver4 webauthn fido
person garethb    schedule 21.10.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я недавно проделал некоторую работу по реализации этого, но только на данный момент для второго фактора.

Короче говоря, он должен работать в контексте браузера конечного пользователя (учитывая, что это API JavaScript), поэтому на самом деле он должен быть встроен в поток входа через конечную точку authorize.

Например (при условии, что локальный клиент или сеансы IDP еще не существуют):

  1. Пользователь посещает клиентское приложение
  2. Клиент перенаправляется на authorize конечную точку
  3. Авторизовать перенаправление конечной точки на пользовательский интерфейс интерактивной аутентификации, который затем решает, какой метод использовать.
  4. Выполните задачу WebAuthn, проверьте результат и установите файл cookie сеанса
  5. Перенаправить обратно на authorize конечную точку
  6. Выпустить токены и перенаправить обратно клиенту

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

person mackie    schedule 21.10.2019
comment
Спасибо, звучит хорошо. Один вопрос, с шагом 4, где это следует обрабатывать? клиентское приложение? личность? - person garethb; 22.10.2019
comment
Шаг 4 будет обрабатываться в Identity как часть интерактивного процесса входа в систему на основе браузера. Посмотрите пример веб-приложения github.com/abergs/fido2-net-lib, он должен дать вам хорошее представление о том, как они сочетаются друг с другом. - person mackie; 22.10.2019