前言
有這樣一種場景，就是新專案已經整合了認證中心，或者是都用了統一的認證方式(比如現在常用的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綜藝圈”，和我一起學習吧。