В настоящее время я выполняю миграцию существующего монолитного приложения ASP.NET MVC в .NET Core с использованием микросервисов.Часть этой миграции теперь включает использование Identity Server 4 с внешним поставщиком удостоверений.Миграция использует шаблон strangler в том смысле, что мы медленно переносим старую систему, а не выполняем всю миграцию сразу.Поэтому мы должны поддерживать унаследованную систему, которая использует аутентификацию сеансов на основе файлов cookie, а также новые API-интерфейсы микросервиса, использующие токены-носители JWT.
В настоящее время я изучаю самый простой способ поддержки обоих типов аутентификации, пока миграция не станет 100% выполнено.С веб-приложением все в порядке, поскольку оно все еще использует бритвенные страницы и проверку подлинности на стороне сервера, поэтому может легко установить сеанс, а также передать мой токен для проверки подлинности API.Мой мобильный клиент - проблема, он построен с использованием ионной и ранее использованной аутентификации сеанса на стороне сервера (до моего времени ..).Теперь, когда я использую протокол OpenID Connect с внешним провайдером, весь мой процесс аутентификации обрабатывается на клиенте для мобильных устройств, поэтому сеанс не создается.
Опция 1: Использование строгомой токен-носитель JWT для аутентификации в моем мобильном приложении и каким-то образом настроить мои контроллеры MVC, чтобы иметь возможность использовать аутентификацию JWT, если она присутствует в заголовке, или аутентификацию cookie, если в запросе присутствует cookie (устаревшее веб-приложение).Я не уверен, что мне нужно будет создать собственное промежуточное программное обеспечение для этого или есть способ настроить что-то в автозагрузке без необходимости создания промежуточного программного обеспечения, а атрибут controllers [authorize] просто будет знать, что нужно использовать cookie или аутентификацию на носителе.Я нашел статью, объясняющую, что это возможно в Core, но еще не нашел ничего, связанного с .NET Framework.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
//configuration goes here
});
app.UseJwtBearerAuthentication(new JwtBearerAuthenticationOptions
{
//configuration goes here
}
Вариант 2: Создайте новую конечную точку на моем сервере приложений прежних версийи чтобы мой мобильный клиент передал токен носителя, который я получил, конечной точке для установления сеанса.Теперь мой мобильный клиент может передавать cookie и токен JWT на предъявителя в каждом запросе и позволять серверу решать, как он хочет проверить.Это, очевидно, добавляет небольшую сложность, поскольку сейчас я сохраняю срок действия файлов cookie, токенов и т. Д., Но это произойдет только до завершения миграции.
Вариант 3: ???
Вопрос: Я потратил много времени на изучение обоснованности любого из вариантов и в основном только на получение ресурсов.связанных с ядром .NET, но очень мало .NET Framework.Мне нужно будет поддерживать устаревшее приложение только в течение короткого периода времени, поэтому на данный момент я ищу самое простое решение, а не самое чистое.Хотите знать, может ли кто-нибудь, кто сделал подобную миграцию, предложить решение или вопрос о том, как он смог это сделать?