上一篇我介紹了JWT的生成驗證及流程內容，相信大家也對JWT非常熟悉了，今天將從一個小眾的需求出發(fā)，介紹如何強制令牌過期的思路和實現過程。

.netcore項目實戰(zhàn)交流群（637326624），有興趣的朋友可以在群里交流討論。

一、前言

眾所周知，IdentityServer4?默認支持兩種類型的 Token，一種是?Reference Token，一種是?JWT Token?。前者的特點是?Token?的有效與否是由?Token?頒發(fā)服務集中化控制的，頒發(fā)的時候會持久化?Token，然后每次驗證都需要將?Token?傳遞到頒發(fā)服務進行驗證，是一種中心化的驗證方式。JWT Token的特點與前者相反，每個資源服務不需要每次都要都去頒發(fā)服務進行驗證?Token?的有效性驗證，上一篇也介紹了，該?Token?由三部分組成，其中最后一部分包含了一個簽名，是在頒發(fā)的時候采用非對稱加密算法進行數據的簽名，保證了?Token?的不可篡改性，校驗時與頒發(fā)服務的交互，僅僅是獲取公鑰用于驗證簽名，且該公鑰獲取以后可以自己緩存，持續(xù)使用，不用再去交互獲得，除非數字證書發(fā)生變化。

二、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，參數如下圖所示。

查看是否校驗成功，從返回的狀態(tài)碼和active結果判斷，如果為true校驗成功，如果為false或者401校驗失敗。

我們直接從數據庫里刪除剛才授權的記錄，然后再次提交查看結果,返回結果校驗失敗。

然后我們校驗下Jwt Token，同樣的方式，先生成jwt token,然后進行校驗，結果如下圖所示。

可以得到預期結果。

三、強制過期的方式

1、簡易黑名單模式

在每次有Token請求時，資源服務器對請求的Token進行校驗，在校驗有效性校驗通過后，再在黑名單里校驗是否強制過期，如果存在黑名單里，返回授權過期提醒。資源服務器提示Token無效。注意由于每次請求都會校驗Token的有效性，因此黑名單最好使用比如Redis緩存進行保存。

實現方式：

此種方式只需要重寫Token驗證方式即可實現。

優(yōu)點

實現簡單，改造少。

缺點

1、不好維護黑名單列表

2、對認證服務器請求壓力太大

2、策略黑名單模式

建議黑名單有一個最大的弊端是每次請求都需要對服務器進行訪問，會對服務器端造成很大的請求壓力，而實際請求數據中99%都是正常訪問，對于可疑的請求我們才需要進行服務器端驗證，所以我們要在客戶端校驗出可疑的請求再提交到服務器校驗，可以在Claim里增加客戶端IP信息，當請求的客戶端IP和Token里的客戶端IP不一致時，我們標記為可疑Token，這時候再發(fā)起Token校驗請求，校驗Token是否過期，后續(xù)流程和簡易黑名單模式完成一致。

實現方式

此種方式需要增加Token生成的Claim，增加自定義的ip的Claim字段，然后再重寫驗證方式。

優(yōu)點

可以有效的減少服務器端壓力

缺點

不好維護黑名單列表

3、強化白名單模式

通常不管使用客戶端、密碼、混合模式等方式登錄，都可以獲取到有效的Token，這樣會造成簽發(fā)的不同Token可以重復使用，且很難把這些歷史的Token手工加入黑名單里，防止被其他人利用。那如何保證一個客戶端同一時間點只有一個有效Token呢？我們只需要把最新的Token加入白名單，然后驗證時直接驗證白名單，未命中白名單校驗失敗。校驗時使用策略黑名單模式，滿足條件再請求驗證，為了減輕認證服務器的壓力，可以根據需求在本地緩存一定時間（比如10分鐘）。

實現方式

此種方式需要重寫Token生成方式，重寫自定義驗證方式。

優(yōu)點

服務器端請求不頻繁，驗證塊，自動管理黑名單。

缺點

實現起來比較改造的東西較多

綜上分析后，為了網關的功能全面和性能，建議采用強化白名單模式來實現強制過期策略。

四、強制過期的實現

1.增加白名單功能

為了增加強制過期功能，我們需要在配置文件里標記是否開啟此功能，默認設置為不開啟。

然后重寫Token生成策略，增加白名單功能，并使用Redis存儲白名單。白名單的存儲的Key格式為clientId+sub+amr，詳細實現代碼如下。

然后定一個通用緩存方法，默認使用Redis實現。

然后重新注入下ITokenResponseGenerator實現。

現在我們來測試下生成Token，查看Redis里是否生成了白名單？

Reference Token生成

客戶端模式生成

密碼模式生成

從結果中可以看出來，無論那種認證方式，都可以生成白名單，且只保留最新的報名單記錄。

2.改造校驗接口來適配白名單校驗

前面介紹了認證原理后，實現校驗非常簡單，只需要重寫下IIntrospectionRequestValidator接口即可，增加白名單校驗策略，詳細實現代碼如下。

然后把接口重新注入，即可實現白名單的校驗功能。

只要幾句代碼就完成了功能校驗，現在可以使用PostMan測試白名單功能。首先使用剛生成的Token測試，可以正確的返回結果。

緊接著，我從新生成Token，然后再次請求，結果如下圖所示。

發(fā)現校驗失敗，提示Token已經失效，和我們預期的結果完全一致。

現在獲取的Token只有最新的是白名單，其他的有效信息自動加入認定為黑名單，如果想要強制token失效，只要刪除或修改Redis值即可。

有了這個認證結果，現在只需要在認證策略里增加合理的校驗規(guī)則即可，比如5分鐘請求一次驗證或者使用ip策略發(fā)起校驗等，這里就比較簡單了，就不一一實現了，如果在使用中遇到問題可以聯系我。

五、總結與思考

本篇我介紹了IdentityServer4里Token認證的接口及實現過程，然后介紹強制有效Token過期的實現思路，并使用了白名單模式實現了強制過期策略。但是這種實現方式不一定是非常合理的實現方式，也希望有更好實現的朋友批評指正并告知本人。

實際生產環(huán)境中如果使用JWT Token，建議還是使用Token頒發(fā)的過期策略來強制Token過期，比如對安全要求較高的設置幾分鐘或者幾十分鐘過期等，避免Token泄漏造成的安全問題。

至于單機登錄，其實只要開啟強制過期策略就基本實現了，因為只要最新的登錄會自動把之前的登錄Token強制失效，如果再配合signalr強制下線即可。

項目源代碼地址：https://github.com/jinyancao/Czar.IdentityServer4

總結

以上是生活随笔為你收集整理的【.NET Core项目实战-统一认证平台】第十三章 授权篇-如何强制有效令牌过期的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。