前言

有这样一种场景，就是新项目已经集成了认证中心，或者是都用了统一的认证方式(比如现在常用的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再试试，如下：

好了，自定义认证的思路就是这样，只需要根据项目对接的情况，在校验逻辑那块改成项目实际的场景即可。

源代码地址：

https://gitee.com/CodeZoe/dot-net-core-study-demo/tree/main/CustomAuth

总结

以上方案其实在之前的项目也使用到了，最近对接新老系统时，又需要这块，间隔时间有点长，有一些小细节忘了，所以赶紧记录一下，下次直接翻文章就行啦。

关注“Code综艺圈”，和我一起学习吧。