какую аутентификацию использовать - PullRequest
0 голосов
/ 05 сентября 2018

Наше приложение в настоящее время написано на .NET Framework + Razor и традиционной аутентификации членства.

Я пытаюсь его модернизировать, поэтому я начал работать над решением .net core + реакции, но оно должно взаимодействовать с существующим приложением.

Так что в настоящее время у нас есть старый монолит и другое ядро ​​.net apis, называемое реагировать. Реакция встроена в бритву.

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

Я не совсем уверен, какое решение можно или нужно использовать. Я знаю такие модные слова, как токен на предъявителя, .NET Identity, OAuth + OpenId, но могу ли я использовать любое из них в этой ситуации, чтобы использовать его для защиты API, а также для «традиционного» бритвенного приложения? И где мне хранить токен? Должен ли я сохранить его в сеансе приложения-бритвы и передать его в React?

Мне нужно решение, в котором учетные данные пользователя хранятся в нашей собственной базе данных, а не в списке единого входа Google или Facebook.

Есть хороший учебник для этого?

1 Ответ

0 голосов
/ 05 сентября 2018

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

Я бы предложил аутентификацию на краю приложения, чтобы добиться хорошего разделения для работы с существующим приложением. Я хотел бы создать легкий метод, который получает запрос от клиента и дает шлюзу API подтверждение личности пользователя способом, который может проверить API. Я бы пошел с OAuth и OpenId Connect протокол для достижения этого разделения. Кроме того, взгляните на IdentityServer , это продукт с открытым исходным кодом, который позволяет легко реализовать единый вход и контроль доступа (аутентификация) в веб-приложениях и HTTP-API.

  • OpenId Connect для аутентификации пользователей
  • OAuth, чтобы ограничить совместную работу для этих вызовов легких методов
  • веб-токены JSON (JWT) для удостоверений пользователей

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

...