Прежде всего, обратите внимание, что вы не используете ASP.NET Core Identity там.Identity - это стек управления пользователями, который строит поверх системы аутентификации.Похоже, вы используете OpenID Connect с IdentityServer в качестве поставщика, поэтому ваше веб-приложение будет потреблять только информацию OIDC, но не должно управлять своими собственными удостоверениями (хотя может быть, что IdentityServer использует ASP.NET Core Identity, хотя).
Способ работы стека аутентификации в ASP.NET Core заключается в том, что вы можете настроить набор схем аутентификации.Некоторые из этих схем предназначены для использования в комбинации, например, схема аутентификации cookie редко используется сама по себе, но существуют также схемы, которые можно использовать совершенно отдельно (например, аутентификация JWT Bearer).
Аутентификационные действия
В мире аутентификации есть определенные действия, которые вы можете выполнять:
Аутентификация : Аутентификация в основном означает использование данногоинформация и попытка аутентификации пользователя с этой информацией.Таким образом, будет предпринята попытка создать идентификатор пользователя и сделать его доступным для платформы.
Например, схема аутентификации cookie использует данные cookie для восстановления идентификатора пользователя.Или схема аутентификации Bearer JWT будет использовать токен, который предоставляется как часть заголовка Authorization в запросе для создания идентификатора пользователя.
Challenge :Когда схема аутентификации оспаривается, она должна предлагать пользователю аутентифицировать себя.Например, это может означать, что пользователь будет перенаправлен в форму входа в систему или что будет перенаправление на внешний поставщик аутентификации.
Запретить : приСхема аутентификации запрещена, схема в основном просто отвечает тем, что говорит пользователю, что он может не делать того, что он пытался сделать.Обычно это ошибка HTTP 403 , которая может быть перенаправлением на страницу ошибки.
Вход в систему : при схеме аутентификациивыполняется вход в систему, затем указывается, что схеме нужно взять существующего пользователя (ClaimsPrincipal) и каким-то образом сохранить его.Например, при входе пользователя в схему проверки подлинности cookie в основном создается файл cookie, содержащий личность этого пользователя.
Выход : Это знак, обратный знаку-in и в основном скажет схеме аутентификации удалить это постоянство.Выход из схемы cookie приведет к истечению срока действия файла cookie.
Обратите внимание, что не все схемы аутентификации могут выполнять все параметры.Вход и выход, как правило, являются специальными действиями.Схема проверки подлинности с использованием cookie-файлов является примером, который поддерживает вход и выход, но, например, схема OIDC не может этого сделать, но будет использовать другую схему для входа и сохранения идентификатора.Вот почему вы обычно будете видеть схему cookie вместе с ней.
Типичный поток аутентификации
Схемы аутентификации могут использоваться явно.Когда вы используете один из методов расширения аутентификации на HttpContext, например, httpContext.AuthenticateAsync(), вы всегда можете явно указать, какую схему аутентификации вы хотите использовать для этой операции.
Так что, если вы, например, хотите войти в систему со схемой аутентификации cookie "Cookie", вы можете просто назвать ее так из своего кода:
var user = new ClaimsPrincipal(…);
await httpContext.SignInAsync(user, "Cookie");
Но на практике,прямой и явный вызов аутентификации - это не самая распространенная вещь.Вместо этого вы, как правило, будете полагаться на платформу для аутентификации за вас.И для этого платформе необходимо знать, какую схему аутентификации использовать для какой операции.
Вот для чего AuthenticationOptions.Вы можете настроить эти параметры так, чтобы вы могли явно определить, какую схему аутентификации использовать по умолчанию для каждого из этих действий аутентификации:
Обычно вы не настраиваете все те свойства.Вместо этого у платформы есть некоторые запасные варианты по умолчанию, поэтому вы можете настроить только подмножество этих свойств.Логика такова:
- Аутентификация:
DefaultAuthenticateScheme или DefaultScheme - Вызов:
DefaultChallengeScheme или DefaultScheme - Запретить:
DefaultForbidScheme, или DefaultChallengeScheme, или DefaultScheme - Вход:
DefaultSignInScheme, или DefaultScheme - Выход:
DefaultSignOutScheme, или DefaultScheme
Как видите, каждое из действий аутентификации возвращается к DefaultScheme, если конкретное действие по умолчанию не настроено.Итак, что вы обычно видите, это конфигурируемый DefaultScheme, а затем настраиваются конкретные действия для тех, где требуется другая схема.
Ваш пример показывает это довольно хорошо: с OIDC вам понадобитсясхема входа, которая может сохранять идентичность, предоставленную внешним поставщиком аутентификации.Таким образом, вы обычно видите схемы проверки подлинности OIDC и cookie:
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
});
Для пользователя обычное взаимодействие осуществляется через схему проверки подлинности cookie: при обращении к веб-приложению схема проверки подлинности cookie пытается выполнить проверку подлинности.они используют свои куки.Поэтому использование схемы проверки подлинности cookie в качестве схемы по умолчанию для всех операций.
Исключение составляет проблема проверки подлинности: в этом случае мы хотим, чтобы пользователь был перенаправлен к поставщику OIDC, чтобы он мог войти в систему там.и вернуться с личностью.Таким образом, мы устанавливаем схему OIDC по умолчанию challenge .
Кроме того, мы также связываем схему OIDC со схемой cookie.Когда пользователь получает запрос и входит в систему со своим внешним поставщиком аутентификации, он будет отправлен обратно в веб-приложение со своей внешней идентификацией.Однако схема OIDC не может сохранить эту идентичность, поэтому она подписывает , используя другую схему - схему cookie - которая затем сохраняет идентичность от имени схемы OIDC.Таким образом, схема cookie создаст cookie для идентификатора OIDC, и при следующем запросе схема cookie (которая является схемой по умолчанию) сможет снова аутентифицировать пользователя с использованием этого cookie.
Поэтому в большинстве случаев вам будет достаточно просто указать схему по умолчанию, а затем, в зависимости от настроек аутентификации, вы можете изменить одно или два явных действия.Но теоретически вы можете полностью настроить очень сложную настройку различных значений по умолчанию и нескольких схем: инфраструктура дает вам большую гибкость здесь.