歡迎光臨
每天分享高質量文章

【.NET Core專案實戰-統一認證平臺】第十三章 授權篇-如何強制有效令牌過期

上一篇我介紹了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 TokenReference 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

 

    赞(0)

    分享創造快樂