IdentityServer4 Внешняя аутентификация без файлов cookie

Question

У меня проблемы с пониманием того, как работает аутентификация ASP.NET Core.

Я хочу реализовать аутентификацию токена доступа JWT с токенами обновления.Насколько мне известно, это отраслевой стандарт для аутентификации клиента (мобильное приложение, веб-приложение SPA).В целях безопасности я бы предпочел не реализовывать собственную логику авторизации, включая генерацию JWT и обработку обновлений токенов.Поскольку ASP.Net изначально не поддерживает это, естественно, я бы выбрал IdentityServer4, большую библиотеку с открытым исходным кодом для обработки такого рода вещей.

Однако IdentityServer4 в значительной степени основан на OAuth, иЯ не уверен, как это работает с приложениями SPA и мобильными приложениями (клиенты, которым я доверяю).Это требует, чтобы клиент перенаправил на какую-то произвольную веб-страницу, чтобы ввести свои учетные данные, а затем перенаправить обратно в приложение.Валовой.Я никогда не видел, чтобы у такого крупного приложения, как Snapchat, Instagram и т. Д. Был такой поток аутентификации, когда вы перенаправляетесь на какую-то веб-страницу / браузер во время входа в систему.К счастью, IdentityServer4 имеет небольшую функцию для обработки аутентификации по имени пользователя / паролю для моих доверенных клиентов (http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html)

Отлично, это, кажется, соответствует моим потребностям. Но ... Теперь я хочу добавить аутентификацию Facebook. IdentityServer4 допускает внешнюю аутентификацию , однако она по-прежнему основана на файлах cookie (насколько мне известно). Для этого требуется, чтобы приложение Android / iOS / SPA перенаправляло на веб-страницу, а затем перенаправляло обратно в приложение.не идеален с точки зрения пользователя. Facebook предоставляет собственные мобильные SDK для обработки этого типа аутентификации, который возвращает маркер доступа, поэтому нет необходимости перенаправлять на веб-страницы с помощью файлов cookie.

Теперь допустим, мое приложение для iOSиспользует Facebook SDK, чтобы получить токен доступа для пользователя и отправить его бэкэнду. Бэкэнд проверяет токен на соответствие SDK Facebook, а затем регистрирует локального пользователя в своей собственной базе данных.

Теперь, когда тот же самыйПользователь iOS пытается войти в приложение, приложение сгенерирует токен доступа Facebook для этого пользователяиз SDK и отправьте его на сервер.Однако я не уверен, как использовать IdentityServer4 для генерации JWT для пользователя, так как мне нужны имя пользователя и пароль этого пользователя.Вот где я застрял.Кажется, я борюсь с библиотекой, и это заставляет меня поверить, что я что-то неправильно понимаю.

TLDR;IdentityServer4, по-видимому, в значительной степени основано на файлах cookie, которые не очень хорошо вписываются в веб-страницы мобильных приложений / SPA, когда вы перенаправлены назад и вперед с веб-страниц аутентификации.Я использую не тот инструмент для работы?Какие есть альтернативные решения?

Answer 1

Это абсолютно подходящий инструмент для работы, если вы хотите получить то, что вам дают OpenID Connect и OAuth2.Похоже, что вам может потребоваться убедить, и может случиться так, что ваш сценарий использования не нуждается в полной широте предлагаемой функциональности.

Если у вас в игре несколько клиентских приложений и API, то я думаю, что использование OpenID Connect и IdentityServer4 правильный выбор на данный момент.

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

1. Клиентское приложение полностью отделено от того, как на самом деле выполняется аутентификация, будь то федерация, социальный вход (Facebook в вашем случае), многофакторное сканирование, сканирование сетчатки глаза и т. Д. Ваш идентификационный сервер имеет дело со всей этой сложностью и является единой точкойуправления (и неудачи - так что сделайте его в высшей степени доступным!)
2. Возможен единый вход - если они уже вошли в ваш IDP, они могут сразу войти (хотя у вас есть полный контроль над потоком -хотите, чтобы они каждый раз соглашались или подтверждали запрос на вход - вы можете это сделать)
3. Если у пользователя в браузере настроен менеджер паролей, он тоже будет работать

И iOS, и Android предлагают API для выполнения этой работы и работы.Если ваш внешний вид и веб-интерфейсы выглядят одинаково, поток от PoV ​​пользователя совсем не сотрясается.

Вы все равно можете использовать токены обновления (в конечном счете, защищенные платформой), поэтому вам на самом деле не нужноВ любом случае, делайте интерактивный поток очень часто.

Некоторое дополнительное чтение ниже.От отрасли ушло немало размышлений, поэтому определенно стоит переварить текущую лучшую практику.

https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Текущая лучшая практика IETF: https://tools.ietf.org/html/rfc8252

Не заставляйте Скотта ненавидеть вас;): https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications

Для клиентских приложений браузера SPA OIDC предоставляет неявный тип предоставления и использует механизм автоматического обновления и мониторинга сеанса IDP для поддержки сеанса.Проверьте библиотеку oidc-client-js, которая реализует этот подход.