Microsoft Identtiy & Identity Server 4 взаимосвязи потоков процессов

Question

Я работаю над созданием серии микро-сервисов с использованием Aspnet Core.Мобильное приложение, настольное приложение и веб-приложение будут использовать сервисы через API REST Http.

Для аутентификации пользователя я использую платформу Aspnet Core Identity, но я представляю создание учетных записей пользователей черезAPI REST.Клиенты выполняют вызов REST с информацией об учетных данных, и мой API использует API Identity Microsoft для обеспечения пользователя.Пользователю будет разрешено использовать отдельные серверы ресурсов с помощью сервера аутентификации с использованием IdentityServer4.

У меня есть два вопроса, по которым я не смог найти четких указаний с точки зрения безопасности.Должен ли проект Aspnet Core, использующий Microsoft Identity для создания пользователя, находиться в независимом проекте Aspnet Core от проекта, который обрабатывает аутентификацию через IdentityServer4?Есть ли недостатки, которые нужно разделить, что мне нужно учитывать?

В Microsoft Identity API есть шаблон и Razor Views, которые можно использовать для обработки аутентификации с точки зрения сервера, включая перенаправления при создании учетной записи иливход в систему и т. д. Если я делаю все через SPA или клиентские нативные приложения, то что-то не так с предоставлением POST API, который принимает информацию о пользователе, создает учетную запись через UserManager<T> и возвращает UserId?

Я хочу предоставить отдельную страницу входа, аналогичную FB / Google / Twitter и т. Д., Для Auth, которая будет использоваться в любом приложении, которое хочет авторизовать пользователя для моих служб.Я обычно не рассматриваю создание учетной записи как часть процесса OAuth.Типично, что вы разрешаете перенаправления на страницу создания учетной записи, которая перенаправляет обратно клиенту при успешном создании учетной записи, или этот процесс обычно используется только для проверки подлинности через потоки OAuth?

Answer 1

Главное, когда вы думаете об интерфейсе управления безопасностью, это как защитить этот интерфейс.И самый безопасный подход на сегодняшний день - это аутентификация на основе файлов cookie с файлами cookie того же сайта (кстати, MVC использует по умолчанию).Учтите, что при выборе безсерверного шаблона SPA.Для целей управления приложение со строгим бэкэндом намного более безопасно, чем доступ на основе токенов к распределенным API-интерфейсам.

Что касается хостинга приложений, то @VidmantasBlazevicius абсолютно прав, единственной стратегии не существует: хостинг всехСлужбы в одном приложении проще, поэтому лучше подходят для систем со средней нагрузкой.Но с увеличением количества пользователей и запросов на аутентификацию вы можете захотеть масштабировать, и отделение пользовательского интерфейса управления от аутентификации является одним из способов справиться с этим.

Answer 2

Я бы посоветовал рассмотреть возможность использования одного сервиса для IDS4 и ASP.NET Identity, поскольку они могут быть интегрированы и предоставлять вам всю необходимую функциональность (аутентификация и управление пользователями).

IDS4 имеет примеры и хорошую документацию по этому вопросу.

Мне кажется, что разделение их было бы чрезмерным инженерным делом.

один пример: когда IDS4 генерирует токен доступа для пользователя, вы должны получить утверждения, роли и проверить имя пользователя и пароль, все это хранится в ASP.NET Identity.

Так что для более подробной информации вы можете проверить документы Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html

или я с удовольствием проверяю мой небольшой пост в блоге, который я постарался дать более подробный и пошаговый. https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/

Начните со ссылки IDS4, потому что этого может быть достаточно :)