Я хочу перенести немного устаревший проект в современную эпоху, и я не совсем уверен, как.
У меня есть веб-приложение, которое использует куки-аутентификацию, а некоторые вещи построены поверх него.Он получает токен от внешнего провайдера аутентификации X, поэтому есть конечные точки, такие как X/login, которые показывают форму входа в систему и выполняют обратный вызов с токеном в параметрах запроса.X/verify, на который я отправляю токен в параметрах запроса, и он возвращает утверждения, если токен действителен.
Процесс входа в систему выглядит следующим образом:
- Новый пользователь переходит на авторизованную страницу
- промежуточное ПО перенаправляет на
X/login, так как нет файлов cookie. - поставщик проверки подлинности X вызывает конечную точку обратного вызова с токеном в моем веб-приложении после успешного входа в систему
- Веб-приложение проверяеттокен, получить утверждения, создает
ClaimsPrincipal с использованием утверждений - , выполняет вход (
httpContext.SignInAsync(scheme, principal)) с использованием схемы проверки подлинности cookie по умолчанию и упомянутого принципала - Проверка подлинности пользователя.
Я хочу изменить это на аутентификацию Bearer Token и иметь отдельное клиентское приложение и API, чтобы клиентское приложение перенаправляло на провайдера аутентификации, получало токен в качестве обратного вызова и использовало его для аутентификации запросов к API, а API проверял бы его с использованием аутентификацииПоставщик.
Хотя получить токен довольно просто, я не уверен, как настроить API для использования токена Bearer и проверить его.Сначала я просто подумал, что поменяю схему аутентификации с cookie на auth, и этого должно быть достаточно, но я быстро понял, что httpContext.SignInAsync() нельзя использовать со схемой аутентификации на носителе Jwt, и теперь я немного растерялся.В то же время это выглядит довольно просто (всего 2 простых конечных точки, чтобы получить токен и проверить его), но в то же время это выглядит запутанным, как в том, как использовать существующую инфраструктуру asp.net для обработки всего остального.
Редактировать : потенциально я мог бы просто добавить глобальное промежуточное программное обеспечение в API, чтобы проверять токен доступа и проверять его вручную для каждого запроса, но на самом деле это не похоже на хорошее решение, поскольку А) делает 1 дополнительный запросдля каждого обычного запроса к API просто для проверки токена.B) Нет ClaimsPrincipal для доступа к пользовательским данным, таким как электронная почта и т. Д. Теперь все будет хорошо, поскольку я не хочу доступа к этим данным, но все же.