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

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

一、前言

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

二、Reference Token的用法

上一篇已經(jīng)介紹了JWT Token的整個(gè)生成過程，為了演示強(qiáng)制過期策略，這里需要了解下Reference Token是如何生成和存儲的，這樣可以幫助掌握IdentityServer4所有的工作方式。

1、新增測試客戶端

由于我們已有數(shù)據(jù)庫，為了方便演示，我直接使用SQL腳本新增。

這里添加了認(rèn)證類型為Reference Token客戶端為clientref，并分配了客戶端授權(quán)和能訪問的scope，然后我們使用PostMan測試下客戶端。

如上圖所示，可以正確的返回access_token，且有標(biāo)記的過期時(shí)間。

2、如何校驗(yàn)token的有效性？

IdentityServer4給已經(jīng)提供了Token的校驗(yàn)地址http://xxxxxx/connect/introspect，可以通過訪問此地址來校驗(yàn)Token的有效性，使用前需要了解傳輸?shù)膮?shù)和校驗(yàn)方式。

在授權(quán)篇開始時(shí)我介紹了IdentityServer4的源碼剖析，相信都掌握了看源碼的方式，這里就不詳細(xì)介紹了。

核心代碼為IntrospectionEndpoint,標(biāo)注出校驗(yàn)的核心代碼,用到的幾個(gè)校驗(yàn)方式已經(jīng)注釋出來了。

有了上面的校驗(yàn)代碼，就可以很容易掌握使用的參數(shù)和校驗(yàn)的方式，現(xiàn)在我們就分別演示JWT Token和Reference token兩個(gè)校驗(yàn)方式及返回的值。

首先需要新增資源端的授權(quán)記錄，因?yàn)樾ｒ?yàn)時(shí)需要，我們就以mpc_gateway為例新增授權(quán)記錄，為了方便演示，直接使用SQL語句。

首先我們測試剛才使用Reference token生成的access_token，參數(shù)如下圖所示。

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

我們直接從數(shù)據(jù)庫里刪除剛才授權(quán)的記錄，然后再次提交查看結(jié)果,返回結(jié)果校驗(yàn)失敗。

然后我們校驗(yàn)下Jwt Token，同樣的方式，先生成jwt token,然后進(jìn)行校驗(yàn)，結(jié)果如下圖所示。

可以得到預(yù)期結(jié)果。

三、強(qiáng)制過期的方式

1、簡易黑名單模式

在每次有Token請求時(shí)，資源服務(wù)器對請求的Token進(jìn)行校驗(yàn)，在校驗(yàn)有效性校驗(yàn)通過后，再在黑名單里校驗(yàn)是否強(qiáng)制過期，如果存在黑名單里，返回授權(quán)過期提醒。資源服務(wù)器提示Token無效。注意由于每次請求都會(huì)校驗(yàn)Token的有效性，因此黑名單最好使用比如Redis緩存進(jìn)行保存。

實(shí)現(xiàn)方式：

此種方式只需要重寫Token驗(yàn)證方式即可實(shí)現(xiàn)。

優(yōu)點(diǎn)

實(shí)現(xiàn)簡單，改造少。

缺點(diǎn)

1、不好維護(hù)黑名單列表

2、對認(rèn)證服務(wù)器請求壓力太大

2、策略黑名單模式

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

實(shí)現(xiàn)方式

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

優(yōu)點(diǎn)

可以有效的減少服務(wù)器端壓力

缺點(diǎn)

不好維護(hù)黑名單列表

3、強(qiáng)化白名單模式

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

實(shí)現(xiàn)方式

此種方式需要重寫Token生成方式，重寫自定義驗(yàn)證方式。

優(yōu)點(diǎn)

服務(wù)器端請求不頻繁，驗(yàn)證塊，自動(dòng)管理黑名單。

缺點(diǎn)

實(shí)現(xiàn)起來比較改造的東西較多

綜上分析后，為了網(wǎng)關(guān)的功能全面和性能，建議采用強(qiáng)化白名單模式來實(shí)現(xiàn)強(qiáng)制過期策略。

四、強(qiáng)制過期的實(shí)現(xiàn)

1.增加白名單功能

為了增加強(qiáng)制過期功能，我們需要在配置文件里標(biāo)記是否開啟此功能，默認(rèn)設(shè)置為不開啟。

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

然后定一個(gè)通用緩存方法，默認(rèn)使用Redis實(shí)現(xiàn)。

然后重新注入下ITokenResponseGenerator實(shí)現(xiàn)。

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

Reference Token生成

客戶端模式生成

密碼模式生成

從結(jié)果中可以看出來，無論那種認(rèn)證方式，都可以生成白名單，且只保留最新的報(bào)名單記錄。

2.改造校驗(yàn)接口來適配白名單校驗(yàn)

前面介紹了認(rèn)證原理后，實(shí)現(xiàn)校驗(yàn)非常簡單，只需要重寫下IIntrospectionRequestValidator接口即可，增加白名單校驗(yàn)策略，詳細(xì)實(shí)現(xiàn)代碼如下。

然后把接口重新注入，即可實(shí)現(xiàn)白名單的校驗(yàn)功能。

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

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

發(fā)現(xiàn)校驗(yàn)失敗，提示Token已經(jīng)失效，和我們預(yù)期的結(jié)果完全一致。

現(xiàn)在獲取的Token只有最新的是白名單，其他的有效信息自動(dòng)加入認(rèn)定為黑名單，如果想要強(qiáng)制token失效，只要?jiǎng)h除或修改Redis值即可。

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

五、總結(jié)與思考

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

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

至于單機(jī)登錄，其實(shí)只要開啟強(qiáng)制過期策略就基本實(shí)現(xiàn)了，因?yàn)橹灰钚碌牡卿洉?huì)自動(dòng)把之前的登錄Token強(qiáng)制失效，如果再配合signalr強(qiáng)制下線即可。

項(xiàng)目源代碼地址：https://github.com/jinyancao/Czar.IdentityServer4

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。