前言

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