前言
有这样一种场景，就是新项目已经集成了认证中心，或者是都用了统一的认证方式(比如现在常用的JWT)，这样对于项目之间的对接就显得比较方便，至少在认证这块还是能减少一些工作量的。但当上线的老项目需要对接新项目时，由于有些老项目通常会个性化的生成Token或者是通过一些标识传到后台进行认证，再加上老项目运行稳定和投入人力比较少的情况，很多时候都需要新的项目兼容老的认证方式，这个时候就可以考虑自定义的认证方式了。
正文
其实主要的原理就是根据项目的认证传参情况，从请求头或请求参数中取出对应的Token或标识进行验证即可；和很多小伙伴们一样，一开始想到的方法是通过授权过滤器的方式实现即可，但其实可以模仿AddJwtBearer的认证方式自己实现一个，主要的逻辑就是继承AuthenticationHandler之后，在HandleAuthenticateAsync方法中编写自己的验证就OK了，详细步骤如下：
1. 编写验证逻辑
这里还是创建一个WebAPI项目进行演示
1.1 定义自己的AuthenticationScheme
就像Bearer一样，定义自己的Scheme，在这个类里也可以定义需要的配置信息，可以在验证逻辑的时候用到，如下：
1.2 继承AuthenticationHandler编写自己的验证逻辑
添加一个类继承自AuthenticationHandler，重写HandleAuthenticateAsync方法，在里面可以写和业务相关的任何验证逻辑：
1.3 定义一个扩展方法，像AddJwtBearer一样使用
为了方便调用，按照规范为AuthenticationBuilder定义一个扩展方法：
2. 使用自定义的认证方式
上面的验证逻辑都写完了，接下来就像使用JWT认证一样直接使用即可，由于演示环境用的.NET5，在Startup.cs中注册相关服务和加上对应的认证中间件就行。
然后在需要认证控制器或Action方法上打上Authorize属性就行啦：
以上就是自定义认证方式的使用步骤，是不是很简单，来试一下效果：
加上Token再试试：
用Postman组装请求头试试，如下：
在请求头中加个Token再试试，如下：
好了，自定义认证的思路就是这样，只需要根据项目对接的情况，在校验逻辑那块改成项目实际的场景即可。
源代码地址：
总结
以上方案其实在之前的项目也使用到了，最近对接新老系统时，又需要这块，间隔时间有点长，有一些小细节忘了，所以赶紧记录一下，下次直接翻文章就行啦。
关注“Code综艺圈”，和我一起学习吧。
