【问题标题】:Understanding Mvc Core Identity了解 Mvc 核心标识
【发布时间】:2018-11-01 23:37:13
【问题描述】:

我一直在试图找到一个解释,但是关于身份如何与 mvc 核心一起工作的时间很短。我已经找到了许多关于如何实现它的指南,而且我有,而且一切都很好,但我想至少在高层次上理解它。

我目前的理解是,当用户传递他们的凭据时,身份库将发出一个令牌,并且该令牌将被写入浏览器的 cookie。现在,所有进一步的请求都将根据该浏览器 cookie 识别用户。但是,我似乎无法找到过去的解释。为什么这是安全的,为什么我不能偷那个 cookie 并将其用作我自己的?我知道还有更多内容,可能我对上述部分的理解是错误的。

无论如何,我要么在寻找有关其工作原理的高级解释,要么寻找可以深入研究细节的良好参考。

【问题讨论】:

  • 你已经阅读过官方文档了吗?
  • 我有,但我能找到的只是有关如何在您的项目中实现此功能的示例。这不是我在这里问的。
  • 我不介意投反对票,但至少解释一下你为什么这样做。我认为我没有做任何违反这里的规则的事情。我已经先完成了我的研究,但无法提出任何建议,所以我在这里寻求帮助。
  • Identity 最好理解为身份验证提供程序/存储。它主要关注用户管理:创建、更新、分配角色和其他声明、密码、双因素等。您在这里实际谈论的是 ASP.NET Core 身份验证和授权子系统,特别是 cookie 身份验证。 Identity 仅支持这一点,但您可以使用 IdentityServer、Auth0 甚至完全自定义的系统轻松切换 Identity。

标签: c# asp.net-core-mvc asp.net-identity identity asp.net-core-identity


【解决方案1】:

身份如何与 mvc 核心一起工作。

正如@Chris Pratt 所说,您所说的是安全子系统。既然说的是cookie,那我就以cookie的认证方案为例。

内置安全性主要存在于 4 个项目中:

  • HttpAbstractions:核心接口和类,如认证方案、认证处理器、认证票据等。
  • Security:认证中间件、cookie认证、JWT Bearer认证、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 之前运行,因此您可以根据需要拦截请求。

当您想在不登录的情况下访问受[Authorize] 保护的url 时,它会要求您通过某种方案登录。您可以根据需要配置服务以使用不同的方案,例如 Jwt Bearer、cookie 等。

如果您使用的是 cookie 方案, CookieAuthenticationHandler 将承担重任:

  • Signin:当你认为你已经验证了用户主体时,将发出一个新的 cookie。
  • Authenticate:验证客户端发送的cookie
  • Signout :删除cookie

请注意,所有这些都是由Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationHandler 完成的,即aspnet/Security 中定义的处理程序,而不是aspnet/Identity

为什么我不能偷那个 cookie 并将其用作我自己的?

  1. 当然,您可以窃取某人的 cookie 并将其用作您自己的。实际上,如果 Alice 的 cookie 被 Bob 窃取(比如说通过XSSsniffering),Bob 将被视为 Alice。 ASP.NET Core(以及 PHP/Python/Java 等其他技术)无法防止这种情况发生,要防止窃取还有很多工作要做:

    • 网站应该使用HTTPS而不是HTTP
    • 编码&lt;,&gt;,&lt;img onclick='javascript:'等字符以防止XSS
    • ...
  2. 另外,有时你不需要偷别人的 cookie。通过CSRF,您只需“借用”他的cookie。

为什么这样安全

通常,即使理论上可以窃取某人的 cookie 或借用某人的 cookie,也只会在您以错误的方式开发应用程序或以不安全的方式部署应用程序时发生。

另一件事是您几乎无法在客户端伪造 cookie。

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2019-07-19
  • 1970-01-01
  • 2011-01-27
  • 1970-01-01
  • 2011-04-13
  • 1970-01-01
  • 2017-07-17
相关资源
最近更新 更多