Сервер идентификации - это провайдер идентификации OpenID Connect. (openidConnect построен поверх OAuth2). Это означает, что приложение сервера идентификации будет обрабатывать все, что связано с доступом и токенами идентификации, различными потоками, федеративной идентификацией и делегированием полномочий, другими словами, выполняя все операции, связанные с аутентификацией и авторизацией. Подход OpenId connect и OAuth2 идеально подходит при работе с распределенными системами, требующими централизованной безопасности. Это означает, что использование IS4 гарантирует, что все ваше приложение, которое доверяет вашему серверу идентификации, будет обрабатывать аутентификацию и авторизацию консолидированным образом.
Для самой вашей архитектуры IS4 кажется хорошей отправной точкой, но:
- Поскольку клиенты React и Admin имеют две разные страницы входа, должны ли они обе использовать IS4 для авторизации и аутентификации?
IS4 - это отдельное приложение, которое будет выпускать, проверять и управлять токенами клиентов ypu и, в конечном итоге, токенами. Так что, скорее всего, процесс аутентификации будет выполняться на стороне IS4. Это очень похоже на сторонних поставщиков удостоверений (например, facebook или google. Помните кнопки «войти с помощью google»?), Но в вашем случае у вас есть собственная служба идентификации - IS4, размещенная как приложение. Таким образом, страница входа должна быть на стороне IS4, но вы можете настроить макет.
- Проект администратора будет проектом ASP.NET MVC и не будет вызывать API из другого проекта, поэтому какие GrantTypes я должен использовать и должен использовать для него IS4?
Ответ, как всегда, зависит от вас. Если вам требуется некоторая идентификация в вашем приложении (а не анонимный доступ), тогда использование IS возможно и даже предпочтительнее. Однако, если ваша административная часть является приложением на стороне сервера, наилучшим подходящим потоком предоставления является «код авторизации» (связь сервер-сервер от имени пользователя).
13.04.2017
