как именно идентичность работает с ядром MVC.
Как говорит @ Крис Пратт , вы говорите о подсистеме безопасности. Поскольку вы говорите о cookie, я возьму в качестве примера схему аутентификации cookie.
Встроенную защиту можно найти в основном в 4 проектах:
- HttpAbstractions : основные интерфейсы и классы, такие как схема аутентификации, обработчик аутентификации, билет аутентификации и т. Д.
- Безопасность : промежуточное программное обеспечение для проверки подлинности, проверка подлинности с использованием cookie-файлов, проверка подлинности на носителе JWT, проверка подлинности OAuth2.0 (Google / Facebook / Microsoft / ...) и т. Д.
- Идентичность : проект скаффолда с именем «Идентичность», который помогает управлять пользователем / ролями / утверждениями / и т. Д.
- DataProtection : API защиты данных для защиты и снятия защиты данных. Вы можете использовать его как API для шифрования и дешифрования.
Точкой входа для понимания того, как работает аутентификация, является AuthenticationMiddleware. Это промежуточное ПО будет пытаться аутентифицировать каждый запрос, если это возможно:
public async Task Invoke(HttpContext context)
{
// ...
// Give any IAuthenticationRequestHandler schemes a chance to handle the request
var handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
{
var handler = await handlers.GetHandlerAsync(context, scheme.Name) as IAuthenticationRequestHandler;
if (handler != null && await handler.HandleRequestAsync())
{
return;
}
}
// Use the default scheme to authenticate request
var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
if (defaultAuthenticate != null)
{
var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
if (result?.Principal != null)
{
context.User = result.Principal;
}
}
await _next(context);
}
Обычно это промежуточное ПО запускается раньше других промежуточных программ / mvc, поэтому вы можете перехватывать запросы по мере необходимости.
Если вы хотите получить доступ к url, защищенному [Authorize] без входа в систему, вам будет предложено выполнить вход по некоторой схеме. Вы можете настроить свои службы так, чтобы они использовали разные схемы, например, Jwt Bearer, файлы cookie и т. Д.
Если вы используете схему cookie,
CookieAuthenticationHandler сделает тяжелую работу:
- Signin : будет выдан новый файл cookie, если вы считаете, что подтвердили учетную запись пользователя.
- Аутентификация : проверка cookie, отправленного клиентом
- Выйти : удалить куки
Обратите внимание, что все это выполняется Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationHandler, то есть обработчиком, определенным в aspnet/Security, а не aspnet/Identity library .
почему я не могу украсть этот cookie и использовать его как свой собственный?
Конечно, вы можете украсть чье-то печенье и использовать его как свое собственное. На самом деле, если Боб украл печенье Алисы (скажем, через XSS или sniffering), Боб будет считаться Алисой. ASP.NET Core (и другие технологии, такие как PHP / Python / Java) не могут предотвратить это, и для предотвращения кражи достаточно много:
- Веб-сайт должен использовать
HTTPS вместо HTTP
- кодировать символы, такие как
<, >, <img onclick='javascript:' и т. Д., Чтобы предотвратить XSS
- ...
Кроме того, вам не нужно иногда красть чье-то печенье. К CSRF вы просто «одолжите» его печенье.
Почему это безопасно
Как правило, даже если теоретически можно украсть чей-то cookie или заимствовать чей-то cookie, это произойдет только в том случае, если вы неправильно разрабатываете свое приложение или внедряете их небезопасным способом.
Другое дело, что вы вряд ли сможете подделать cookie на стороне клиента.