客官，来看看AspNetCore的身份验证吧

开篇

这段时间潜水了太久，终于有时间可以更新一篇文章了。

通过本篇文章您将Get：

• Http的一些身份验证观点
• 在AspNetCore中实现身份验证方案
• JWT等观点的基础知识
• 使用Bearer Token对WebAPI举行珍爱
• 一些验证中的小细节
• 微信小程序验证的源代码

时长为大约有十五分钟，内容丰富，建议先投币再上车旁观

本文附带了通俗Bearer JwtToken验证和微信小程序验证登录的源代码，效果图您可以参考下方的Gif图片。

。

该项目的堆栈地址，您可以点击这里举行跳转。

注:该项目通过uni-app来编写，没有领会过的同伙也不用忧郁，本文最后会对该演示项目举行一些说明注释。

正文

对于大多数应用系统来说，险些都离不开身份验证。由于我们需要珍爱一些数据，不让“非法”用户获取。以是我们必须得凭据自身项目情形来添加对身份验证的支持功效。

在这之前，我们先不要思量什么Bearer,JWT,OpenId等观点，遗忘他们，让我们从0最先。

若是我们现在有一个Web Api应用程序，接纳了AspNetCore来编写。在没有任何尺度协媾和框架的支持下，我们会若何对一个用户举行身份验证呢？

最基础的验证

或许您已经想到了，既然用户是通过账号和密码来登录的，那么我就可以通过账号和密码来对他举行验证呀。让用户直接把用户名和密码传给我，我不就知道是他了吗？

那怎么传值呢？用Get？ 好比下方的这个请求：

> http://your-address/Book/Get?user='myName'&pwd='abc123'

这样每次请求的时刻我就能够获得用户名和密码了，然后通过和数据库校验就能够判断当前的用户是不是通过了。

然则这种方式您很快就能发现问题，每个api不都要增添一些参数吗？url是一个很通俗的器械，这样很容易就把账号密码泄露了。

以是，我们改变一下方案，把用户名和密码放到Http的请求头（Header）内里，该项的Header Key值叫做Authorization。

那么我们的请求可能就像这样了:

Request URL: http://your-address/Book/Get

Request Header:
:method: GET
Authorization:myName:abc123

固然，若是把用户名密码信息在加密一下就更好了。为了让服务端能够解密，以是接纳了Base64加密。以是请求就可能成为了这个样子:

Request URL: http://your-address/Book/Get

Request Header:
:method: GET
Authorization:bXlOYW1lOmFiYzEyMw==

这样服务端很容易就能够通过Header来举行用户验证。 获取header的Authorization项 -> 举行Base64解密 -> 凭据数据库内容判断用户名和密码 -> 验证通过。

这种验证方案是不是很简朴呢？ 然则到这里，您可能会说，这种方案也太简陋了吧。若是我阻挡到了请求的包，那不即是这小我私家直接把用户名和密码送到我的手里吗？

确实是这样的，若是我们在举行Http请求的时刻受到了中间人攻击，那么账号和密码都将被泄露，“非法分子”可以拿着获得的用户名和密码登录系统举行任何操作。

以是，我们必须接纳Https传输。这样，中间人获得的信息是加密的，他也无法剖析出来。

而这种直接把用户名和密码放置在请求头中传输的方案，正是随同Http协议一同提出的Basic验证方案：Wiki Basic access authentication。

身份信息自包罗

当身份验证服务和咱们的营业系统粘连在一起的时刻（好比传统的单体环境），基础的验证方案实在能够很好的知足咱们的需求。然则，当身份验证服务被自力出来，我们就需要使用过多的成本去举行验证：好比身份验证服务部署在服务器A，而营业服务在服务器B，若是根据上面的验证方案，我们每接见一次服务器B，那么服务器B就需要把该请求所携带的信息转发至服务器A去验证，服务器A凭据转发过来的Header中的Authorization项，从数据库中或者内存中查询对应的身份信息，举行通过或者拒绝操作，然后服务器B再凭据服务器A所返回的信息举行处置。

而网络通信的成本是昂贵，若是不需要身份验证的话，只需要一次就能够完成营业，而现在，会被拆分成多次，时间开销是很大的。再一点，所有的接见压力都市被推到身份验证服务器，若是有B,C,D三个营业服务器，那岂不是所有的服务器都要于身份验证服务器举行交互？

以是，我们必须得使用另外的手段来应对这种身份验证方案，那就是自包罗的身份信息：当身份验证服务器验证通过时，就发一个类似于令牌的器械给客户端，与上面的那种方案较为差别的是，该令牌是一种包罗了需要验证信息的加密字符串。

好比我们每次身份验证都是为了获取到userId这一项信息。基础验证方案中，我们通过通报username和password来获取userId。而现在，我们就直接让令牌来包罗userId这一项内容，而以后我们每次携带该令牌去接见API的时刻，就不需要再到数据库中举行查找用户来获取Id了。这样就能大幅度够减缓服务器的查找压力。

用户通报了username和password到身份验证服务器，服务器通过与数据库中的用户信息举行匹配，发现是userId = 3的用户。此时身份验证服务器则发生一个类似于userId:3&userName:myName的字符串返回给用户，下一次用户接见时，就携带上该字符串在请求头部举行通报，而其它的服务器看到该信息后，就以为现在的用户是userId为3的用户，则返回该用户对应的数据。

上方是咱们凭据已有的结论来模拟的验证方案，然则您会发现，该方案实在有很大的破绽。 好比客户端吸收到了userId:3&userName:myName的验证令牌，然则他突然起了坏心眼，既然我是id为3的用户，那一定在我之前就有id为2或者为1的用户，那我直接改一下这个数值，然后再举行接见，是不是就可以获得其它用户的信息了呢？ 固然，谜底一定为是的！

以是我们必须要做的事情就是：“将效果加密”。固然，加密的方式有对称加密和非对称加密。对称加密就是加密和解密共用一个密匙，好比密码为123，那么加密使用123来加密，解密也需要用123来解密，以是密匙是必须得严酷珍爱，否则泄露之后就凉凉啦。而非对称加密就是发生一个公钥和私钥，可以用私钥来加密，然后别人可以用公钥来举行解密验证。

在咱们传输令牌的这个案例中，对称加密和非对称加密咱们都可以使用。若是我们此处使用了AES的对称加密算法，而加密的密码为12345，那么userId:3&userName:myName将会被我们加密为：

JX9lHmBFuhckNOP3sGG0/X0TooCjlsXBGyI3Gz1UudA=

此时，客户就没有办法再修改该内容了。而营业服务器，使用12345来对该令牌举行解密就能够获取到信息了。

然则有些时刻，身份验证服务器不愿意与其它营业服务器共享12345这个密匙，由于知道的人越多，泄露的风险就越大，那么他就可以使用非对称加密的方案。身份验证服务器独享一个私钥来举行加密，而营业服务器可以从身份验证服务器处获取到公钥来举行验证。

这样我们就完成了自包罗的身份信息令牌的发表，然则不要急，另有问题。由于这个令牌的生效区间是什么时刻呢？ 我们现在只是发表了信息，然则您想啊，这样不是一发出去了之后就一发不可收拾了吗？ 用户可以一直使用该令牌来举行接见，纵然他已经更改了密码，然则令牌照样依旧生效的，若是令牌一泄露，那他的账号就永远的凉凉了。

以是，我们必须得给这个令牌一个过时时间，若是令牌超过了过时时间，那么该令牌就是无效的。以是我们依旧让过时时间被自包罗在令牌信息中，以是原有的令牌就可能被我们改成这样:userId:3&userName:myName&expireTime:2020/02/02 12:00。这样营业服务器举行验证的时刻，就首先验证是否过时就行啦，果真爽歪歪~。

Javascript Object人人族

在看了上面先容的基础身份验证方案之后，信赖您已经对身份验证有了一点的领会和熟悉。实在，上面的方案也是现代身份验证的雏形，然则本质上原理是相通的。

既然是雏形，那么现在一定有更完善的身份验证方案。以是，请抬好小板凳，准备好瓜子花生，即将举行飞升。

接下来，您将看到WebApi最为常见的身份验证方案JWT。在提及JWT之前，我想您可能已经听过OAuth2.0或者OpenID Connect等尺度验证框架，亦或是在.NET平台下，它们的实现方案IdentityServer。

关于OAuth2.0和OpenID的观点，由于篇幅有限，将会在下一篇文章中为人人带来先容.

来看一看OpenID Connect的架构图，您可以看到，JWT是作为它的底成实现支持。以是，对于领会JWT来说是需要的。

然则在该图中，除了JWT您还会看到其它的类似单词，好比:JWS、JWE、JWK等等。然则当您想去对他们举行领会的时刻，很负疚，百度居然不靠谱了。

不要张皇，在有了上面基础验证方案的思绪之后，这些对于您来说都不是问题。

这些JW*的命名，实在他们都属于一种器械：Javascript Object Signing and Encryption (JOSE)。从命名中实在就可以看出，它是卖力了署名和加密解密的事情。而Javascript Object对于人人来说就更不生疏了，它界说了若何组织一套数据结构的规范。

在连系我们上面讲的谁人自包罗的验证，那时我们界说了一个类似于userId:3&userName:myName&expireTime:2020/02/02 12:00的令牌，该令牌我使用了&符号来举行拼接，虽然能相符我们的需求，然则很显然这不是一个业界通用的做法。这就导致其它系统与咱们的系统对接的时刻都需要重写一次该验证的处置流程。

以是，我们需要一个更通用，人人都认可的规范。而JOSE则正是充当了这样的一个角色。

对于Python用户来说，对于jose可能不是太生疏，由于在Py中有着很着名的jose处置库。而在.NET中就没有对该要害字很着名的支持库。

好啦，回到这些规范上来，我们先来看看他们各自的一些界说：

JWA

JWA规范了算法的简写形貌，好比以下是应用于JWT的某些算法，就好像咱们在JWT中经常看到的alg:HS256，该HS256就是在该规范中被注释的术语，代表了使用HMAC对称加密后再使用SHA-256举行哈希摘要。

JWS

JWS规范指出了使用JSON花样来示意加密内容。JWS由三个部门所组成：JOSE Header、JWS Payload和JWS Signature。

而JWS的焦点在于第三个部门：JWS Signature署名。它凭据前面的两个部门来盘算处第三个部门的署名，防止该信息再通报的历程中被修改。（想一想我们最初的加密自包罗令牌）。

署名的盘算规则如下：

摘要算法(加密算法(ASCII(BASE64URL(UTF8(JWS Protected Header)) || ‘.’ || BASE64URL(JWS Payload))))

好比我们有这样的一个头部和荷载内容:

{
    "typ":"JWT",
    "alg":"HS256"
}

{
    "iss":"joe",
    "exp":1300819380,
    "http://example.com/is_root":true
}

那么我们会对头部举行编码加密，通过BASE64URL加密，则对应内容为eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9。同样我们再使用BASE64URL加密荷载部门，对应内容为eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。

由于BASE64URL加密是可逆的，以是我们还需要对这些内容举行署名，才气在通报时珍爱数据平安。凭据头部的信息我们得知使用的是HS256，这就对应着JWA内里的信息，我们需要通过HMAC来加密，然后再使用SHA-256举行摘要。最终再使用BASE64URL编码该署名，我们就能够得出署名的最终效果为：dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk。

最后，将三个部门通过.链接起来，就组成了一个整体加密内容：

 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.
 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.
 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

看到这里，您可能会说，这不是JWT吗？花样明显一模一样，是的，JWS和JWA等就是JWT的基础，JWT在这之上提供了新的规范，好比荷载中的Claim等信息。下面将会讲到。

JWK

JWK规范界说了若何以JSON花样示意非对称密钥，并引入了密钥集聚集(JWKS)，该聚集为提供者公布署名和加密密钥提供了一种方式。

来看看JWK的花样例子：

{
    "kty":"RSA",
    "kid":"i0wnn",
    "use":"sig",
    "n":"mdrLAp5GR8o5d5qbwWTYqNGuSXHTIE6w9HxV445oMACOWRuwlOGVZeKJQXHM9cs5Dm7iUfNVk4pJBttUxzcnhVCRf
9tr20LJB7xAAqnFtzD7jBHARWbgJYR0p0JYVOA5jVzT9Sc-j4Gs5m8b-am2hKF93kA4fM8oeg18V_xeZf11WWcxnW5YZwX
9kjGBwbK-1tkapIar8K1WrsAsDDZLS_y7Qp0S83fAPgubFGYdST71s-B4bvsjCgl30a2W-je9J6jg2bYxZeJf982dzHFqV
QF7KdF4n5UGFAvNMRZ3xVoV4JzHDg4xe_KJE-gOn-_wlao6R8xWcedZjTmDhqqvUw",
    "e":"AQAB"
}

其中Kty（不是Ktv哈）示意了该算法的系列，好比RSA或者EC等。kid示意了该条密匙内容的id。而内里的n和e划分代表了RSA加密中的modulus和exponent。

再想想最初的我们注释的自包罗令牌，对于非对称加密，我们需要从服务端获取到公钥，那么现在问题就来了，公钥怎么示意呢？ 而JWK相当于就干了这样一件事。

什么？你问我这器械哪儿见过？您的IdentityServer4内里是不是公开了一个节点叫做.well-known/openid-configuration/jwks，眼熟吧？jwks不就是这一个器械吗？ 点击这里看看吧！

音视频前沿：新一代 AV1 视频标准究竟是怎样一种存在？

JWT

来吧，万众期待的JWT。在JOSE家族中，我们看到了这么多个JW*的器械，实在感受上它们都是为了最后这一项器械所服务，那就是JWT。这也是为什么，人人仅仅听过JWT，而对其它的观点都不是太领会的缘故原由。

JWT是一种紧凑的、URL平安的方式，用于示意双方之间要传输的声明。JWT中的声明被编码为JSON工具，该工具用作JSON Web署名(JWS)结构的有用负载或JSON Web加密(JWE)结构的明文，从而使声明能够通过新闻身份验证。

对于我们常用的JWT，是接纳了JWS的署名式加密方案。以是结构就是 “A.B.C”的样子，用Header来形貌了署名加密所用的算法，该形貌遵照了JWA，而使用Playload来包罗咱们所需要的器械，在JWT内里，它们叫做JWT Claims Set，而JWT提出了许多内置的Claim规范，下面我们会看到。最后是Signature，这就是基于JWS所获得的内容。

JWT规范界说了七个可选的、已注册的声明（Claim），并允许将公共和私人声明包罗在令牌中，这七个已登记的声明是：

固然，仅仅靠这些值我们一样平常是无法处置完整营业逻辑的，好比我们往往需要将用户邮箱等信息放入Token中，以是我们可以在荷载中放入我们自界说的一些项，只要保证不要和内置的命名冲突就行啦。

Bearer Token

这个观点应该是很多多少同砚经常搞晕的一个观点，可能人人都以为，Bearer Token就即是JWT。

固然不是啦，由于Bearer是HTTP Authorization的类型规范，而JWT是一个数据结构的规范。

还记得我们在最初的时刻提到过一个Basic验证吗？ 它的花样是这样的：

Authorization : Basic xxxxxx

在HTTP 1.0中提出了Authorization: <type> <credentials>这样的花样。 若是Basic类型的验证是Authorization : Basic，那么你已经可以想到Bearer是什么样子了。

人人都遵守了这样的规范，才气不乱套，以是为什么有时刻我们取消掉Bearer要害字，有些框架就会不处置该Token。

关于Bearer，它是随同OAuth2.0所提出，该规范仅仅界说了Bearer Token的花样（也就是需要带上Bearer要害字在header中），并没有说过Token一定要使用JWT花样。

以是若是是Bearer即是JWT是纰谬的。

同该Bearer所提出的观点另有access_token和refresh_token。它们都是同OAuth2.0一起降生的，同样的，它们于JWT也并没有直接的关系，以是并非我一定要用JWT来天生access_token和refresh_token，另有就是当我使用JWT的时刻，并非一定要使用refresh_token。

然则就像我们最初设想的一样，若是不使用自包罗的验证，服务器将蒙受伟大的压力。以是在OAuth2.0中，照样推荐人人使用JWT,而该方案也同样具有一个尺度规范。

AspNet Core中的身份验证

有了这些基础知识之后，我们再来看看AspNetCore中是若何实现身份验证的，在这里我们同样以WebApi的验证方案来解说，关于基本的Cookies验证方案，您可以直接查阅官方文档，然则对于验证来说，原理险些都是一样的。

在这之前，您将有许多个要害类需要领会：Claim、ClaimsIdentity、ClaimsPrincipal。

Claim，是身份示意的最小单元，它由焦点的Type和Value属性组成。好比一小我私家会有许多标签，好比身份证号码,邮箱号码,手机号码等等。当您需要验证这某一项信息时，就可以将它申明为一个Claim,好比:

new Claim('email', "bob@gmail.com")

ClaimsIdentity:是一组Claim的合集，一个用户或者一个事物往往有多个标签，以是我们可以将它抽象成个高级的事物，而ClaimsIdentity就是该事物。从ClaimsIdentity的组织函数您就可以看出，它接受了一个IEnumerable<Claim>。

// 建立一个用户身份，注重需要指定AuthenticationType，否则IsAuthenticated将为false。
var claimIdentity = new ClaimsIdentity("myAuthenticationType");
// 添加几个Claim
claimIdentity.AddClaim(new Claim(ClaimTypes.Name, "bob"));
claimIdentity.AddClaim(new Claim(ClaimTypes.Email, "bob@gmail.com"));

ClaimsPrincipal：是一组ClaimsPrincipal的合集，又举行了一次更高条理的抽象。好比一个用户有西席的身份，内里有西席ID、西席邮箱的声明，然则同时他还具有拖拉机师傅的身份，具有执业编号等身份，以是此时我们就可以使用ClaimsPrincipal来示意该用户。

而ClaimsPrincipal就成为了示意一个用户的单元，以是在AspNetCore的HttpContext上下文中有一个User的属性，而该属性就是ClaimsPrincipal。而当我们需要验证他是不是拖拉机师傅的时刻，就通过他身上的执业编号就可以验证啦。

AspNetCore中的身份验证，实在就是一个判断身份准确和构建ClaimsPrincipal的历程。以是我们就来看看它是若何处置的。

很明显，由于AspNetCore管道的特征，以是我们一下就能猜到它是在一个较早的中间件中举行的身份验证的。这也是为什么咱们要把app.UseAuthentication();放到前面的缘故原由。

而关于该验证的中间件实在很简朴，它的代码也只有几句：

// 判断当前是否需要举行远程验证，若是是就举行远程验证
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;
    }
}

//获取内陆的验证方案，举行验证
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);

关于该部门的内容，由于篇幅有限，我仅仅从宏观的角度来为人人先容，若是您对于该部门源码剖析有兴趣，可以参考园子中雨夜朦胧的博客.

AspNetCore的验证是凭据scheme来区分的，scheme是什么呢？实在就是咱们的验证方案。一样平常来说，咱们一套系统往往会有多种登录方案，好比博客园，现在就开放了多种外部登录的方案：

而AspNetCore为了便于扩展利便，以是使用了scheme来作用区分方式，这样我们在差别的时刻，指定差别的scheme就能够举行对应的处置：

好比我们现在要举行QQ登录，那么我就需要指定scheme的值为QQ，然后就会找到对应的处置程序来举行处置。

以是，在许多身份验证的地方，您都可以看到方式中会带有scheme这个参数：

HttpContext.SignInAsync(scheme, principal, properties: null);

//我可以这样挪用
context.SignInAsync("QQ",...);  //代表我将使用QQ身份验证方案.

那么这些Handler类中都做了一些什么事情呢？ 这就回到了我们该篇文章最初的时刻，基础验证方案和自包罗验证方案。 好比自包罗验证的JWT验证，那内部一定就是将A.B.C这种花样的字符串举行反剖析，然后看当前的令牌是否过时等操作。

对于内陆的验证方案，我们可以很容易领会验证历程。然则远程的验证方案是特殊的，我们往往会单独来处置它，就像上方的中间件代码，您会发现会优先判断是否为远程验证，然后再执行内陆验证。

为什么呢？由于当使用远程验证方案的时刻，所有的验证逻辑实在都是在外部，那么内陆是若何跟它举行交互举行验证的呢？ 岂非每一次接见API都要去远程验证服务器举行验证一次？

固然不是啦，接下来我将用一个不严谨的远程验证例子来为人人举例。有关真正的远程验证，我会在下一篇文章中为人人先容。

此时有远程验证服务器A，和我内陆营业服务器B。B会在A处申请一个密匙，该密匙是用来举行验证Token。当一个请求来到B的时刻，它会进入到验证中间件，此时我已经在service中注册了对应的远程验证方案（好比services.AddQQAuthentication())。那么B发现该请求没有携带Cookies，那么B将直接拒绝此次请求。

这个时刻客户端会实验举行在登录页举行登录后再接见，登录页为它展示了一个QQ的登录按钮，毫无疑问，用户会点击该按钮举行使用QQ账号登录。而该按钮指向的地址是远程服务器A的登录地址，而地址中携带了回调的内陆地址。好比像这样的URL:”https://QQService.com/sign?callback=http://localhost/sign-qq“。 远程服务器就会处置该请求，守候用户登录乐成之后，他会天生一个Token，然后重定向到内陆服务器的地址，该地址是适才传入的回调地址，好比: “http://localhost/sign-qq?token=xxxxx“。

这个时刻，就证实您正在接见内陆的服务器，而此时注册的远程验证Handler会凭据url的参数举行判断，是否需要举行阻挡处置，好比QQHandler看到了该url的参数为sign-qq，那么它就会以为它要处置该请求，然后它将获取到的Token举行验证（凭据申请到的密匙），验证乐成的话就会剖析出该Token所携带的Claims，自然而然就会天生一个ClaimsPrincipal出来。最终将该ClaimsPrincipal通报给内陆登录方案，天生一个Cookies。这样就完成了内陆的身份验证，下次接见的时刻，带上该Cookies，就会通过验证啦。

以是再来回首中间件代码：

//1. 远程验证乐成，返回到http://localhost/sign-qq?token=xxxxx

//4. 下次正常接见，携带上了Cookies。
var handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
{
    //2.获取到了QQHandler，该Handler看到URL的参数为sign-qq，那么将对他举行处置。处置历程为剖析Token，然后保留到内陆Cookies。

    //5. 发现正常接见时刻的URL不在阻挡范围内，则不做处置。
    var handler = await handlers.GetHandlerAsync(context, scheme.Name) as IAuthenticationRequestHandler;
    if (handler != null && await handler.HandleRequestAsync())
    {
        //3.处置乐成，本次请求竣事。
        return;
    }
}

// 6. 找到内陆验证方案，好比Cookies，那么对携带的Cookies举行验证。
var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
if (defaultAuthenticate != null)
{
    var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
    if (result?.Principal != null)
    {
        context.User = result.Principal;
    }
}

以是远程登录的本质实在就是携带某些信息，让远程服务器返回一个Token，然后内陆凭据从远程服务器处申请到的密匙举行Token剖析的历程。

远程登录往往会衍生出另外一个观点就是外部登录，好比从QQ出登录后返回了qqUserId = 3的用户，然则该用户是存在QQ系统的，我们的系统是没有的，以是需要处置该用户，常用的手段就是绑定该账号。让QQ的userid与我们系统的UserId关联起来。这也是为什么您会在一些框架中看到一些叫做”xxExternalLoginInfo”的表或者信息的缘故原由。

这种方案您可以在该文章所携带的代码中看到，我们使用了微信小程序的用户与营业用户相关联。

AspNetCore中的Jwt Bearer验证

接下来我们将看到若何在AspNetCore中使用JWT Bearer验证。若是您已经读过了上方的内容，信赖您会知道为什么它叫JWT Bearer，而不是JWT或者Bearer。以及为什么微软在提供该包的时刻，没有涉及到refresh_token的发表。

>Install-Package Microsoft.AspNetCore.Authentication.JwtBearer

AspNetCore中的JwtBearer验证方案，是由官方所提供的Microsoft.AspNetCore.Authentication.JwtBearer包所提供，在安装之后，我们可以在Startip.cs中举行注册：

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(o =>
        {
        }

注册时我们需要对JWT举行设置，由于当一个Token过来的时刻，我们需要设置的密匙来对它举行剖析呀，判断它是不是有用，以及是否被窜改。

该设置项的类型为JwtBearerOptions，内里有好些参数，然则对于JWT来说，最最最焦点的是类型为TokenValidationParameters的TokenValidationParameters属性。由于JwtBearerOptions有部门JWT的设置，会受到TokenValidationParameters的约束，好比：

/// <summary>
/// Gets or sets a single valid audience value for any received OpenIdConnect token.
/// This value is passed into TokenValidationParameters.ValidAudience if that property is empty.
/// </summary>
public string Audience { get; set; }

注重，下方的NuGet包可能会让人有点头晕：

TokenValidationParameters类是来自于Microsoft.IdentityModel.Tokens,该包是由AzureAD维护。还记得上面的JWK吗？该包就提供了JWK的.NET实现，和对应的加密算法的实现以及Token的抽象。

若是您想建立JWT，那么您会依赖该团队另外的包。此时您一定会在NuGet上举行搜索，然则…………

MD，好家伙。两个包形貌一模一样，开发一模一样，部门单词也一模一样。我到底选哪一个？它们又有啥区别？

这个时刻就还得需要上面我们所提到的JOSE人人庭的知识啦，在先容JWT的时刻，我们提到了它是由JWS或者JWE来实现的。以是微软就使用Microsoft.IdentityModel.JsonWebTokens来实现了底层JWS和JWE差别建立JWT的方案，而System.IdentityModel.Tokens.Jwt依赖于Microsoft.IdentityModel.JsonWebTokens，接纳更简化的方式来实现JWT。

以是不用说，我们一定应该安装System.IdentityModel.Tokens.Jwt呀，究竟下次数目也多一些。

OK，回到上面，关于TokenValidationParameters的设置，实在都来源于您对JWT的熟悉。好比下面这些设置，若是您已经阅读了上文，实在一下就能看懂：

 .AddJwtBearer(jwtOptions =>
{
    jwtOptions.TokenValidationParameters = new TokenValidationParameters()
    {
        ValidateAudience = false,   //是否验证Audience
        ValidateIssuer = true,  //是否验证Issuer
        IssuerSigningKey = new SymmetricSecurityKey(seurityKey),  //署名的KEY
        ValidIssuer = configuration["JwtConfig:Issuer"], //验证的Issuer信息
        ValidAudience = configuration["JwtConfig:Audience"],//验证的Audience信息
    };
});

这样我们就会验证每一次http请求中所携带的Bearer Token信息。由于实在我们启用了验证Issuer,以是必须保证建立的Token的荷载中是包罗准确的Issuer的，另有就是署名的密匙一定要准确，否则是不会认证通过的。

实在您会发现，在使用Microsoft.AspNetCore.Authentication.JwtBearer的时刻，实在有一些设置是属于OpenID，而该包只是提供了验证jwt的功效，然则并没有建立JWT的功效。由于对于一样平常的WEBAPI应用，实在都市使用OPENID这种单点登录的方案，对于单独的JWT Token验证来说实在照样对照少见的，若是您是简朴的单体应用，那可以使用这样的方案。然则当项目逐步扩大的时刻，照样推荐您使用IdentityServer来实现Oidc登录。

附件代码就使用了内陆服务既建立Token又验证Token的方案

一些你需要注重的小细节

• 当API凭据传入的UserID来获取对应资源的时刻，一定要确保当前验证的用户和传入的ID匹配。

我发现有些同砚经常会犯这样的错误，由于漏写或者遗忘验证，导致一些用户抓包后举行更改参数就获得了一些其它信息。这种错误风险是很大的，设想一下你凭据修改id就获得了其它人的微信聊天记录。 以是我们一定要制止这种错误，在演示项目中，我们使用了[CurrentUser]特征来处置，该特征是MiCake为AspNetCore所实现的自动验证方案，关于实现，您可以参考下方的Github链接。

案例说明

正如您在开头看到的谁人演示图片一样，该演示项目的前端是使用的uni-app来开发的。

可能有些同伙对于纯前端开发会感应对照生疏，由于平时都是使用的Razor这种嵌套C#代码的方式来开发，或者有些同伙已经最先尝鲜Blazor了，然则本质上都是没有脱离C#。(说到Blazor，推荐人人使用 ant-design-blazor )。

然则为了更容易天生小程序的方案，以是最终选择了基于Vue的uni-app。我知道许多人可能和我一样，一直使用着C#的简练语法，对于原生js是很不习惯的。以是，该项目我将所有的代码都转换成了TypeScript，而且全都是类似C#写法的代码。

若是您有使用过WPF或者Winform，您就会感受好像在写Web前端版本的WPF。由于就基础使用来说，TypeScript对于C# er来说，险些没有任何切换成本。您可以来看看下面的几句代码，这是从演示项目中复制过来的：

export default class extends Vue {
    public mobile: string = "";
    public password: string = "";

    public async login() {
        if (!uniHelper.validator.isMobile(this.mobile)) {
            thorUiHelper.showTips(this.$refs.toast, '貌似手机号码不准确呀~');
            return;
        }
        if (uniHelper.validator.isNullOrEmpty(this.password)) {
            thorUiHelper.showTips(this.$refs.toast, '貌似还没有输入密码哦~');
            return;
        }

        var loginInfo = new LoginDto();
        loginInfo.phone = this.mobile;
        loginInfo.password = this.password;
        loginInfo.code = this.code;

        try {
            let result = await this.$httpClient.post<MiCakeApiModel<LoginResultDto>>('/User/Login', loginInfo);
        }catch{
            //...
        }
    }
}

这也是为什么这篇文章拖了好几天的缘故原由，由于我花了好些时间去把所有的代码全转成类似C#语法的Ts代码，只是为了让您能够更好的阅读。

哦，对了。在前端项目内里我引用了Vuex，这是一个全局状态治理的器械。以是搞得有些代码看起来很庞大，刚最先您实在不需要关注它，把它理解为保留一个类似于C#中的static变量就行啦。

附录

以下是本文所提及到各个堆栈的源码地址：

• 前端uni-app演示项目（MiCake实验项目） : https://github.com/uoyoCsharp/MiCake.Samples
• MiCake: https://github.com/uoyoCsharp/MiCake
• MiCake的微信小程序登录验证包: https://github.com/uoyoCsharp/MiCake.Authentication.MiniProgram.WeChat

最后，点个推荐吧