ASP.NET CORE Identity
ASP.NET CORE Identity
先哭一会毕竟研究了好久差点放弃，希望对大家有帮助
什么是 Identity
Identity 在英文中的意思是：身份、标识，通俗易懂一些说白了就是用户管理
ASP.NET Core Identity是微软提供的一套认证（Authentication）和授权（Authorization）机制。认证即为你是谁，而授权则是你能做什么
ASP.NET Core Identity，可以理解为用户管理系统，那么她自然是十分强大的，包含用户管理的方方面面，简单的来讲包括：
用户数据存储（使用任意你喜欢的关系型数据库，从sqllite到mysql、sqlserver等等，由Entity Framwork 支持
登陆、注册外加身份认证
角色管理
基于声明的认证模式Claims Based Authentication
AspNetCore Identity 的前世今生
在 Asp.Net 时代，微软就已经打造了一款包含用户、角色、权限、认证和授权的框架，它的名字叫 AspNet Membership。老一辈的程序员可能听过，但真正使用过的可能很难寻觅，基本上都是项目团队自己开发的。
Membership 在 Asp.Net 时代，也就是 WebForm 的时代，一直到 V3 的版本，后来有了 MVC ，微软才重新命名为 AspNet Identity；
然后随着 AspNetCore 的普及，Identity 框架也随之迁移到了 AspNetCore 平台上
为什么要用AspNetCore Identity
先想一下我们平时怎么实现用户认证的？
我们都是基于cookie或者session的，
多台服务器只能放在cookie,不安全
一台服务器则放在session，即在服务端生成用户相关的 session 数据，发给客户端sesssion_id 存放到 cookie 中，这样用客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户认证。
这种认证方式，可以更好的在服务端对会话进行控制，安全性比较高，但是服务端需要存储 session 数据(如内存或数据库），这样无疑增加维护成本和减弱可扩展性(多台服务器)
而且CSRF 攻击一般基于 cookie 。另外现在趋势前后端分离，如果是原生 app 使用这种服务接口，又因为没有浏览器 cookie 功能，所以接入会相对麻烦。
而基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用户验证后,服务端生成一个 token发给客户端，客户端可以放到cookie 或 localStorage 中，每次请求时在 Header 中带上 token ，服务端收到 token 通过验证后即可确认用户身份。这种方式相对 cookie 的认证方式就简单一些，服务端不用存储认证数据，易维护扩展性强， token 存在 localStorage 可避免 CSRF ， web 和 app 应用这用接口都比较简单。
session ：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。
token ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。
AspNetCore Identity则方便实现token这种方式
怎么使用AspNetCore Identity
我们先来认识几个类
Claims
Claim表示一个声明单元，例如身份证上的信息 姓名：奥巴马；性别：男；民族：肯尼亚等就表示一个Claim
ClaimsIdentity
表示一个证件，例如身份证，所有身份证上的这些Claim组成 ClaimsIdentity
ClaimsPrincipal
表示我们人本身，一个人不止有一个能够表示身份的东西，还有驾驶证、户口本等等，这些都是一个一个的CLaimsIdentity，而我们人本身是一个ClaimsPrincipal。
程序代码如下
Claim nameClaim = new Claim(ClaimTypes.Name, "pangjianxin");
Claim idClaim = new Claim(ClaimTypes.Sid, "1502xxxxxxxxxx");
Claim genderClaim = new Claim(ClaimTypes.Gender, "female");
Claim countryClaim = new Claim(ClaimTypes.Country, "china");
//....省略身份证上面的其他要素....
ClaimsIdentity id = new ClaimsIdentity("身份证");
id.AddClaim(nameClaim);
id.AddClaim(idClaim);
id.AddClaim(genderClaim);
id.AddClaim(countryClaim);
ClaimsPrincipal principal = new ClaimsPrincipal(id);
上面的代码展现了一个身份主体的构造过程
但是Token怎么解析呢？
所以我们就需要一个AuthenticationScheme，表示认证（Authentication）的方式（Scheme:方案）。比如我们现有的技术有Cookie认证，jwtbear认证等，
Scheme作用就是找一个Handler，来实现最终的认证。
这个Handler可能是CookieAuthenticationHandler、JwtSecurityTokenHandler等等。
所以我们需要进行配置，在Startip.cs中ConfigureServices配置
那什么时候进行解析认证呢？我们需要在config中配置认证授权中间件
app.UseAuthentication(); 的作用是在请求的时候通过 ASP.NET Core 中配置的授权认证，读取客户端中的身份标识(Cookie,Token等)并解析出来，存到 context.User 中。
app.UseAuthorization(); 的作用是在请求的时候判断当前访问 Endpoint (Controller或Action)是否使用了 [Authorize]以及配置角色或策略，然后校验Token 是否有效。
使用
在API上添加[Authorize] 特性，用于标识此 Controller 或 Action 需要使用合规的 Token 才能访问。
如果请求不携带令牌，会报 401 (无权限)状态码，导致不能访问 API。
整体流程
- 首先用户输入用户名密码登录网站的时候，我们根据我们选择的认证方式(JWT等)将身份主体信息等生成对应的token
- 服务器将这个票据发送给你的前端，前端进行对应的保存
- 当你再次访问网站的时候，在请求头加上headers[Authorization]=token信息
- 后台会自动根据配置的认证的方式(JWT等)解析出对应的身份主体信息，那保存在哪里呢？
微软很贴心的为我们在HttpContext中加了这样一个User,对应的信息就会保存在这里，这样我们就可以根据对应的信息去进行访问了
而且如果加了[Authorize] 特性会自动根据配置的验证方案进行验证，判断token是否正确
当然Identity还可以授权，大家可以自行研究
参考：
https://www.cnblogs.com/southbean/articles/8555646.html
https://www.cnblogs.com/savorboard/p/aspnetcore-identity.html
https://www.cnblogs.com/fmp/p/Claim.html
https://www.jb51.net/article/183080.htm
