知識星球上一篇我介紹了
JWT的生成驗證及流程內容，相信大家也對JWT非常熟悉了，今天將從一個小眾的需求出發，介紹如何強制令牌過期的思路和實現過程。.netcore專案實戰交流群（637326624），有興趣的朋友可以在群裡交流討論。
一、前言
眾所周知，IdentityServer4 預設支援兩種型別的 Token，一種是 Reference Token，一種是 JWT Token 。前者的特點是 Token 的有效與否是由 Token 頒發服務集中化控制的，頒發的時候會持久化 Token，然後每次驗證都需要將 Token 傳遞到頒發服務進行驗證，是一種中心化的驗證方式。JWT Token的特點與前者相反，每個資源服務不需要每次都要都去頒發服務進行驗證 Token 的有效性驗證，上一篇也介紹了，該 Token 由三部分組成，其中最後一部分包含了一個簽名，是在頒發的時候採用非對稱加密演演算法進行資料的簽名，保證了 Token 的不可篡改性，校驗時與頒發服務的互動，僅僅是獲取公鑰用於驗證簽名，且該公鑰獲取以後可以自己快取，持續使用，不用再去互動獲得，除非數字證書發生變化。
二、Reference Token的用法
上一篇已經介紹了JWT Token的整個生成過程，為了演示強制過期策略，這裡需要瞭解下Reference Token是如何生成和儲存的，這樣可以幫助掌握IdentityServer4所有的工作方式。
1、新增測試客戶端
由於我們已有資料庫，為了方便演示，我直接使用SQL指令碼新增。
這裡添加了認證型別為Reference Token客戶端為clientref，並分配了客戶端授權和能訪問的scope，然後我們使用PostMan測試下客戶端。
如上圖所示，可以正確的傳回access_token，且有標記的過期時間。
2、如何校驗token的有效性？
IdentityServer4給已經提供了Token的校驗地址http://xxxxxx/connect/introspect，可以透過訪問此地址來校驗Token的有效性，使用前需要瞭解傳輸的引數和校驗方式。
在授權篇開始時我介紹了IdentityServer4的原始碼剖析，相信都掌握了看原始碼的方式，這裡就不詳細介紹了。
核心程式碼為IntrospectionEndpoint,標註出校驗的核心程式碼,用到的幾個校驗方式已經註釋出來了。
有了上面的校驗程式碼，就可以很容易掌握使用的引數和校驗的方式，現在我們就分別演示JWT Token和Reference token兩個校驗方式及傳回的值。
首先需要新增資源端的授權記錄，因為校驗時需要，我們就以mpc_gateway為例新增授權記錄，為了方便演示，直接使用SQL陳述句。
首先我們測試剛才使用Reference token生成的access_token，引數如下圖所示。
檢視是否校驗成功，從傳回的狀態碼和active結果判斷，如果為true校驗成功，如果為false或者401校驗失敗。
我們直接從資料庫裡刪除剛才授權的記錄，然後再次提交檢視結果,傳回結果校驗失敗。
然後我們校驗下Jwt Token，同樣的方式，先生成jwt token,然後進行校驗，結果如下圖所示。
可以得到預期結果。
三、強制過期的方式
1、簡易黑名單樣式
在每次有Token請求時，資源伺服器對請求的Token進行校驗，在校驗有效性校驗透過後，再在黑名單裡校驗是否強制過期，如果存在黑名單裡，傳回授權過期提醒。資源伺服器提示Token無效。註意由於每次請求都會校驗Token的有效性，因此黑名單最好使用比如Redis快取進行儲存。
實現方式：
此種方式只需要重寫Token驗證方式即可實現。
優點
實現簡單，改造少。
缺點
1、不好維護黑名單串列
2、對認證伺服器請求壓力太大
2、策略黑名單樣式
建議黑名單有一個最大的弊端是每次請求都需要對伺服器進行訪問，會對伺服器端造成很大的請求壓力，而實際請求資料中99%都是正常訪問，對於可疑的請求我們才需要進行伺服器端驗證，所以我們要在客戶端校驗出可疑的請求再提交到伺服器校驗，可以在Claim裡增加客戶端IP資訊，當請求的客戶端IP和Token裡的客戶端IP不一致時，我們標記為可疑Token，這時候再發起Token校驗請求，校驗Token是否過期，後續流程和簡易黑名單樣式完成一致。
實現方式
此種方式需要增加Token生成的Claim，增加自定義的ip的Claim欄位，然後再重寫驗證方式。
優點
可以有效的減少伺服器端壓力
缺點
不好維護黑名單串列
3、強化白名單樣式
通常不管使用客戶端、密碼、混合樣式等方式登入，都可以獲取到有效的Token，這樣會造成簽發的不同Token可以重覆使用，且很難把這些歷史的Token手工加入黑名單裡，防止被其他人利用。那如何保證一個客戶端同一時間點只有一個有效Token呢？我們只需要把最新的Token加入白名單，然後驗證時直接驗證白名單，未命中白名單校驗失敗。校驗時使用策略黑名單樣式，滿足條件再請求驗證，為了減輕認證伺服器的壓力，可以根據需求在本地快取一定時間（比如10分鐘）。
實現方式
此種方式需要重寫Token生成方式，重寫自定義驗證方式。
優點
伺服器端請求不頻繁，驗證塊，自動管理黑名單。
缺點
實現起來比較改造的東西較多
綜上分析後，為了閘道器的功能全面和效能，建議採用強化白名單樣式來實現強制過期策略。
四、強制過期的實現
1.增加白名單功能
為了增加強制過期功能，我們需要在配置檔案裡標記是否開啟此功能，預設設定為不開啟。
然後重寫Token生成策略，增加白名單功能，並使用Redis儲存白名單。白名單的儲存的Key格式為clientId+sub+amr，詳細實現程式碼如下。
然後定一個通用快取方法，預設使用Redis實現。
然後重新註入下ITokenResponseGenerator實現。
現在我們來測試下生成Token，檢視Redis裡是否生成了白名單？
Reference Token生成
客戶端樣式生成
密碼樣式生成
從結果中可以看出來，無論那種認證方式，都可以生成白名單，且只保留最新的報名單記錄。
2.改造校驗介面來適配白名單校驗
前面介紹了認證原理後，實現校驗非常簡單，只需要重寫下IIntrospectionRequestValidator介面即可，增加白名單校驗策略，詳細實現程式碼如下。
然後把介面重新註入，即可實現白名單的校驗功能。
只要幾句程式碼就完成了功能校驗，現在可以使用PostMan測試白名單功能。首先使用剛生成的Token測試，可以正確的傳回結果。
緊接著，我從新生成Token，然後再次請求，結果如下圖所示。
發現校驗失敗，提示Token已經失效，和我們預期的結果完全一致。
現在獲取的Token只有最新的是白名單，其他的有效資訊自動加入認定為黑名單，如果想要強制token失效，只要刪除或修改Redis值即可。
有了這個認證結果，現在只需要在認證策略裡增加合理的校驗規則即可，比如5分鐘請求一次驗證或者使用ip策略發起校驗等，這裡就比較簡單了，就不一一實現了，如果在使用中遇到問題可以聯絡我。
五、總結與思考
本篇我介紹了IdentityServer4裡Token認證的介面及實現過程，然後介紹強制有效Token過期的實現思路，並使用了白名單樣式實現了強制過期策略。但是這種實現方式不一定是非常合理的實現方式，也希望有更好實現的朋友批評指正並告知本人。
實際生產環境中如果使用JWT Token，建議還是使用Token頒發的過期策略來強制Token過期，比如對安全要求較高的設定幾分鐘或者幾十分鐘過期等，避免Token洩漏造成的安全問題。
至於單機登入，其實只要開啟強制過期策略就基本實現了，因為只要最新的登入會自動把之前的登入Token強制失效，如果再配合signalr強制下線即可。
專案原始碼地址：https://github.com/jinyancao/Czar.IdentityServer4
