Сервер удостоверений 4 и удостоверение ASP.NET Core

Проект, над которым я работаю, состоит из веб-API, одностраничного приложения для реагирования и мобильного приложения. От каждого клиента пользователю потребуется указать свое имя пользователя и пароль, чтобы получить доступ к защищенным частям веб-API. Я установил сервер аутентификации Identity Server 4, который использует мою собственную реализацию интерфейсов IProfileService и IResourceOwnerPasswordValidator, потому что я использую ASP.NET Core Identity. Это позволяет Identity Server получить доступ к ASP.NET Core Identity UserManager, RoleManager и SignInManager, чтобы определить, действительны ли указанные имя пользователя и пароль.

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

Я провел больше исследований об Identity Server и связанных с ним технологиях, потому что я новичок во всем этом. Похоже, что нежелательно использовать тип предоставления ResourceOwnerPassword. Насколько я могу судить, мне кажется, что мне следует использовать тип неявного предоставления, но я не совсем понимаю, как имена пользователей и пароли вписываются в этот поток. Есть ли у кого-нибудь представление о том, какой тип я должен использовать? Возможна ли описанная мною система только с использованием типа предоставления ResourceOwnerPassword?


person Singularity222    schedule 06.03.2017    source источник


Ответы (1)


О типе предоставления пароля владельца ресурса написано об этом в документации IdentityServer:

Тип предоставления пароля владельца ресурса позволяет запрашивать токены от имени пользователя, отправляя имя и пароль пользователя в конечную точку токена. Это так называемая «неинтерактивная» аутентификация и обычно не рекомендуется.

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

(Акцент мой)

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

То же самое с вашей учетной записью Google, например, для входа на другие веб-сайты. Google не хотел бы, чтобы вы вводили это имя пользователя и пароль на свой собственный сайт, потому что вы можете украсть их, и, как правило, именно поэтому тип предоставления пароля владельца ресурса не рекомендуется. Но если вы выполняете интеграцию первой стороны (т.е. веб-сайт принадлежит вам, и вы доверяете себе ввод пользователем своего пароля на вашем веб-сайте), то я не понимаю, в чем проблема.

Вы должны прочитать (и посмотреть на примеры) другие типы потоков / грантов. У них определенно есть свое место, и я не увольняю их, но если вы выполняете интеграцию первой партии, то все должно быть в порядке.

person Mashton    schedule 06.03.2017