Понимание основной идентичности Mvc

как именно тождество работает с ядром mvc.

Как говорит @ Крис Пратт, вы говорите о подсистеме безопасности. Поскольку вы говорите о cookie, я возьму в качестве примера схему аутентификации cookie.

Встроенная безопасность в основном присутствует в 4 проектах:

• HttpAbstractions: основные интерфейсы и классы, такие как схема аутентификации, обработчик аутентификации, билет аутентификации и т. д.
• Безопасность: промежуточное ПО для аутентификации, аутентификация файлов cookie, аутентификация на предъявителя JWT, аутентификация OAuth2.0 (Google / Facebook / Microsoft /...) и так далее.
• Identity: проект под названием «Identity», который помогает управлять пользователями / ролями / утверждениями / и т. д.
• 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 сделает тяжелую работу:

• Войти: выдаст новый файл cookie, если вы считаете, что проверили принципала пользователя.
• Аутентификация: проверить файл cookie, отправленный клиентом
• Выйти: удалить куки

Обратите внимание, что все это выполняется Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationHandler, то есть обработчиком, определенным в aspnet/Security, а не в aspnet/Identity библиотеке.

почему я не могу украсть этот файл cookie и использовать его как свой собственный?

1. Конечно, вы можете украсть чей-то cookie и использовать его как свой собственный. Фактически, если куки Алисы украдены Бобом (скажем, через XSS или sniffering), Боб будет рассматриваться как Алиса. ASP.NET Core (и другие технологии, такие как PHP / Python / Java) не могут предотвратить это, и для предотвращения кражи нужно многое сделать:

   • The website should use HTTPS rather than HTTP
   • кодировать такие символы, как _12 _, _ 13 _, _ 14_ и т. д., чтобы предотвратить XSS
   • ...

2. Кроме того, иногда вам не нужно воровать чей-то cookie. К CSRF вы просто «одолжите» его cookie.

Почему это безопасно

Как правило, даже если теоретически возможно украсть чей-то cookie или одолжить чей-то cookie, это произойдет только в том случае, если вы неправильно разрабатываете свое приложение или развертываете их небезопасным способом.

Другое дело, что вы вряд ли сможете подделать cookie на стороне клиента.