ASP.NET Core 身份验证（一）

前言

这篇文章我想带领大家了解一下 ASP.NET Core 中如何进行的身份验证，在开始之前强烈建议还没看过我写的 Identity 系列文章的同学先看一下。

Identity 入门系列文章：

名词解释

做 Web 开发的都知道 HTTP 协议是无状态的，那么服务端如果想知道此次请求的用户是哪个登录的用户，那么就需要有一种标识每次都被传递到服务端，那么这个标识就是我们都知道的 Cookie（这里我们先不考虑header中携带标识的情况），服务端根据 Cookie 中携带的信息进行识别的一个过程就是身份验证，所有基于 WEB 的服务端都是如此，无关乎语言和框架。

在整个身份验证的过程中，又分为两个部分即认证和授权，很多同学区分不出来这两个东西，因为这两个单词看起来有点像，导致经常认错，这里我教大家一个小方法，就是记住他们的发音，使用某种方法让发音和汉字对应起来，这样就记住了。

Authentication [ɔ:,θenti'keiʃən] 认证

Authorization [,ɔ:θərai'zeiʃən, -ri'z-] 授权

分享一下我的方法，认证的拼音是（renzheng），其中 zheng 包含 en ，同样的 Authentication 也包含 en，这样我就记住了这个单词是认证，那么另外一个就是授权了。

认证：确定用户身份的一个过程。注意是一个过程。

授权：确认用户可以做哪些事情，即权限。

基于 Claims 的身份

在 ASP.NET Core 中主要是使用的基于 Claims 的身份验证，也就是说将用户的属性都抽象成证件单元来表示了，通过证件单元来表示一张身份证。

我们先来回顾一下如何制造一张身份证：

//证件单元

var claims = new List<Claim>()

{

    new Claim(ClaimTypes.Name,"奥巴马"),

    new Claim(ClaimTypes.NameIdentifier,"身份证号")

};

//使用证件单元创建一张身份证

var identity = new ClaimsIdentity(claims, "AuthenticationTypeXXX");

注意，在 new ClaimsIdentity 的时候第二个参数是 AuthenticationType，我在前面文章中讲过这个是 载体类型，也就是实体形式的身份证，对吧？

那么，在使用程序创建一个身份的时候，需要就指定这个载体了，在HTTP验证中，我们将载体设置为Cookies，代码如下：

var cookie身份证 = new ClaimsIdentity(claims, "Cookies");

有了Cookie身份证，我们还需要一个携带者，看过之前文章的可能知道，我讲 ClaimsPrincipal 的时候，一张身份证就不是代表一个人了，而是不通的身份种类，比如你可以同时是一名教师，母亲，商人。如果你想证明你同时有这几种身份的时候，你可能需要出示教师证，你孩子的出生证，法人代表的营业执照证。

所以，我们还需要制造一个人，这个人来携带各种证件，我们就携带上一步制造的 cookie身份证 吧，先携带这一个好了：

var 人 = new ClaimsPrincipal(cookie身份证)

我们来看一下完整的一个代码

//证件单元

var claims = new List<Claim>()

{

    new Claim(ClaimTypes.Name,"奥巴马"),

    new Claim(ClaimTypes.NameIdentifier,"身份证号")

};

//使用证件单元创建一张cookie身份证

var cookie身份证 = new ClaimsIdentity(claims, "Cookies");

//创建一个人携带cookie身份证

var 人 = new ClaimsPrincipal(cookie身份证)

多重身份

当一个人有多种身份的时候，这个时候可能有人会问，什么情况下会有多种身份呢?

举个简单的例子，上面的 cookie身份证 算是一种身份，那么我可能还有比如接入 OAuth的时候使用的 bearer身份证，接入第三方登录时候使用过的 google身份证，facebook身份证，microsoft身份证 等等，这就叫多重身份。

多种身份种的每一种身份都有一个 AuthenticationType 对应一个认证方式，后面我会讲到。

以上，我们理清楚了一个重要的逻辑关系就是：

一个人有多种身份，每个身份都有证件单元和一个认证方式组成。

接下来，你们可能就会认为我就开始介绍认证和授权了。不，很多东西有时候和你想象的并不一样，比如这篇文章也是，所以接下来我要讲的东西是 IdentityModel

IdentityModel

IdentityModel 是一种基于 Claim 的 Identity 库，它提供了一组类用来标识用户身份，以及对这些东西的抽象。

有些同学可能会问，不是已经有 ClaimsIdentity 来表示用户身份了吗？为啥又还有其他的表示用户身份的东西呢？

大哥，身份认证是一整套复杂的东西，包含很多组件，协议，标准，如果很简单就学会了我还用得着写文章教你吗？还是接着介绍吧。

最初，IdentityModel 是属于 WIF(Windows Identity Foundation) 的一部分，WIF 是微软2004年给 .NET 平台搞的一套身份验证框架（包含Claims，Configuration，Metadata，Policy，Servicesd等等），微软想把这个东西作为 .NET 标准框架的一部分，所以它的命名空间是 System.IdentityModel，了解这个东西的人不是很多，不过不知道也没关系，反正这玩意也已经被淘汰了。

在 .NET Core 中， WIF 这些套件只有 System.IdentityModel.Tokens.Jwt 被保留了下来，其他全被扔掉了，为什么呢？

原因是只有 JWT 这部分东西有用，其他的部分更多的是为以前的 Web Servics, WCF 那套分布式东西设计的，那套分布式的东西淘汰了，自然也不必要保留了。

在没有 .NET Core 的时候，我们想实现一套标准的单点登录(SSO)系统就可以利用 System.IdentityModel 因为它已经为我们做了大量工作，并且是标准化的。在 .NET Core 中也需要一些标准的抽象东西那怎么办呢？

微软弄了一套新的 IdentityModel 的库，命名空间为 Microsoft.IdentityModel。很多人甚至都找不到它的源码在哪里，我一开始也没找到，最后发现在 https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet 这个仓库里面。

这个库的组成部分同样都是抽象的部分，包括相关的协议对象，票据的加解密，票据存储等等，也就是说微软给 .NET Core 的身份验证体系又定义了一套抽象的东西，任何第三方基于身份验证的实现库或者框架都要遵循(依赖)他们。

以上的关于 IdentityModel 的介绍和下面我要将的东西关系不是很大，之所以要在这里引入是因为我要为后续的文章做铺垫，在这里引入最合适不过。

接下来我们继续讲解，就开始了认证部分的讲解。

Authentication 认证

我之前讲过奥巴马去杭州旅游的故事，有些同学反映还是看不懂，所以我决定这次配合 ASP.NET Core 中 Cookie 身份认证的过程来讲解。

再次声明，如果你还没看过 Identity 入门一这篇文章，我要求你先跳过去看一下，因为接下来的内容是这篇文章的延申。

我们假设你现在已经知道了人和身份证，然后现在人使用身份证是坐火车。

人就是奥巴马

身份证就是 cookie身份证

我们将开始我们的认证旅程，同时结合我们最熟悉的 HTTP 登录流程。

奥马巴要去乘坐火车，那么现在他要过安检，在Web登录中就是对应的登录，登录要使用用户名密码，但是用户名密码是属于业务逻辑方面的验证，我们不考虑，因为假设是第三方登录就不需要输入用户名和密码了，所以你可以理解为我们假设用户名和密码都正确，现在奥马巴要过安检了。

对应的代码为：

//证件单元

var claims = new List<Claim>()

{

    new Claim(ClaimTypes.Name,"奥巴马"),

    new Claim(ClaimTypes.NameIdentifier,"身份证号")

};

//使用证件单元创建一张身份证

var identity = new ClaimsIdentity(claims,"Cookies");

//使用身份证创建一个证件当事人，也就是奥巴马

var identityPrincipal = new ClaimsPrincipal(identity);

//奥巴马开始过安检

await HttpContext.SignInAsync("Cookies", identityPrincipal);

现在，我们来运行程序，看看会发生什么。你先不用管 HttpContext.SignInAsync 是做什么用的，下面会说。

新建一个ASP.NET Core 空的 MVC 程序，然后在登录的 Action 方法中粘贴以上代码，然后按 F5 运行。

出错了，根据错误信息我们可以看出是因为我们没有注册身份验证的中间件，而且错误已经告诉了我们应该怎么做，我们尝试解决这个错误。

在 Startup.cs 文件中 ConfigureServices 方法注册服务

public void ConfigureServices(IServiceCollection services)

{

    ...

    services.AddAuthentication("Cookies")

        .AddCookie("Cookies"); 

    ...

}

注意，AddAuthentication 这里是指定默认的认证载体类型，AddCookie 这里是注册载体类型的处理程序。

认证部分我会在下一篇中详细介绍，所以这里先大致了解下。

再次 F5 运行发现已经正常了。

我们打开浏览器的 Cookie 查看一下，可以看到多了一项 Cookie 记录

我们可以看到这个 Cookie 的 Name 为 .AdpNetCore.Cookie，Value 为一大长串加密的字符串。

流程讲解

现在我来开始讲 HttpContext.SignIn。

它是一个扩展方法，最终是调用的 IAuthenticationService 接口的 SignInAsync 方法。我们来看下接口的定义：

public interface IAuthenticationService

{

    Task SignInAsync(HttpContext context, string scheme, ClaimsPrincipal principal, AuthenticationProperties properties);

}

有了接口，肯定有实现咯。我们找一下实现在哪里，很容易，根据 ASP.NET Core 的 IOC 来找就行了，很明显在 AddCookie 这个扩展里面。

public void ConfigureServices(IServiceCollection services)

{

    ...

    services.AddAuthentication()

        .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme);

         ↑↑↑ 实现就在这里

    ...

}

我们找到了处理类 CookieAuthenticationHandler 这个对象，我们再来看具体的代码。

protected async override Task HandleSignInAsync(ClaimsPrincipal user, AuthenticationProperties properties)

{

    // Process the request cookie to initialize members like _sessionKey.

    await EnsureCookieTicket();

    var cookieOptions = BuildCookieOptions();

    var signInContext = new CookieSigningInContext(

        Context,

        Scheme,

        Options,

        user,

        properties,

        cookieOptions);

    await Events.SigningIn(signInContext);

    var ticket = new AuthenticationTicket(signInContext.Principal, signInContext.Properties, signInContext.Scheme.Name);

    if (Options.SessionStore != null)

    {

        if (_sessionKey != null)

        {

            await Options.SessionStore.RemoveAsync(_sessionKey);

        }

        _sessionKey = await Options.SessionStore.StoreAsync(ticket);

        var principal = new ClaimsPrincipal(

            new ClaimsIdentity(

                new[] { new Claim(SessionIdClaim, _sessionKey, ClaimValueTypes.String, Options.ClaimsIssuer) },

                Options.ClaimsIssuer));

        ticket = new AuthenticationTicket(principal, null, Scheme.Name);

    }

    var cookieValue = Options.TicketDataFormat.Protect(ticket, GetTlsTokenBinding());

    Options.CookieManager.AppendResponseCookie(

        Context,

        Options.Cookie.Name,

        cookieValue,

        signInContext.CookieOptions);

    var signedInContext = new CookieSignedInContext(

        Context,

        Scheme,

        signInContext.Principal,

        signInContext.Properties,

        Options);

    await Events.SignedIn(signedInContext);

    // Only redirect on the login path

    var shouldRedirect = Options.LoginPath.HasValue && OriginalPath == Options.LoginPath;

    await ApplyHeaders(shouldRedirect, signedInContext.Properties);

    Logger.SignedIn(Scheme.Name);

}

大概步骤分为：

1、创建一个SignIn Cookie 上下文对象

2、将上下文对象转换为票据(Ticket)，转换为票据的目的是为了加密

3、将票据进行加密

4、将加密后的票据写入Cookie

很有意思的是第三步，我需要展开来说下，这也结束。

在第三步加密票据的过程中可以看到有一个 if 判断 if (Options.SessionStore != null)，是做什么用的呢？

可能有些同学会有疑问，我们基于Claim的Cookie存储假如我的证件单元很多，就会生成一个非常大的cookie，每次传输是有性能影响的，并且Cookie是有最大限制的，怎么办呢？

其实解决办法就是我们就可以开启这个 SessionStore，将Cookie存储在服务端例如Redis等缓存中。代码如下：

services.AddSingleton<ITicketStore, MyRedisTicketStore>();

services.AddOptions<CookieAuthenticationOptions>("Cookies")

     .Configure<ITicketStore>((o, t) => o.SessionStore = t);

现在，浏览器中已经存储了用户的身份啦。

以上就是确认用户身份的一个过程，在这个过程中我们使用Cookie来标记用户身份并且存储到浏览器的Cookie了，这个过程就是认证。

其实上面就是 ASP.NET Core 中的 Forms 身份验证中的认证阶段。

扩展阅读

在不使用Cookie的时候怎么确定身份呢？比如在 WEB API 接口中使用的就是 Access Token，这也相当于Cookie中的票据了，那么在 WEB API 中如何确定身份，流程又是怎么样的呢？可以看后续文章。

总结

才把认证写完发现已经这么长了，下篇再来讲讲授权吧。

如果你对 .NET Core 有兴趣的话可以关注我，我会定期的在博客分享我的学习心得。

本文地址：http://www.cnblogs.com/savorboard/p/authentication.html

作者博客：Savorboard

本文原创授权为：署名 - 非商业性使用 - 禁止演绎，协议普通文本 | 协议法律文本