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

Для аутентификации пользователей я использую платформу Aspnet Core Identity, но я представляю создание учетных записей пользователей через REST API. Клиенты выполняют вызов 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?

2
Johnathon Sullinger 31 Май 2019 в 04:37

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 / как в использовании - Asp- нетто - идентичности и - identityserver4 в вашем решении /

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

1
Feras Taleb 31 Май 2019 в 22:05

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

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

1
d_f 3 Июн 2019 в 11:07