如何平衡Token安全性和用戶體驗

今天就跟大家聊聊有關如何平衡Token安全性和用戶體驗，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

下面繼續介紹一組相關概念：Access Token & Refresh Token。

眾所周知，Token作為用戶獲取受保護資源的憑證，必須設置一個過期時間，否則一次登錄便可永久使用，認證功能就失去了意義。但是矛盾在于：過期時間設置得太長，用戶數據的安全性將大打折扣；過期時間設置得太短，用戶就必須每隔一段時間重新登錄，以獲取新的憑證，這會極大挫傷用戶的積極性。針對這一問題，我們可以利用Access / Refresh Token這一概念來平衡Token安全性和用戶體驗。

Access / Refresh Token是什么？

圖 1

上圖表示Access/Refresh Token在客戶端、認證服務器、資源服務器三者之間的傳遞關系，簡單來說：

• Access Token即“訪問令牌”，是客戶端向資源服務器換取資源的憑證；

• Refresh Token即“刷新令牌”，是客戶端向認證服務器換取Access Token的憑證。

Access / Refresh Token如何使用？

圖 2

上圖表示客戶端請求資源的過程中，Access Token 和 Refresh Token 是如何配合使用的：

1. 用戶提供身份信息（一般是用戶名密碼），利用客戶端向認證服務器換取 Refresh Token和Access Token；

2. 客戶端攜帶Access Token訪問資源服務器，資源服務器識別Access Token并返回資源；

3. 當Access Token過期或失效，客戶端再一次訪問資源服務器，資源服務器返回“無效token”報錯；

4. 客戶端通過Refresh Token向認證服務器換取Access Token，認證服務器返回新的Access Token。

用一個現實生活中的比喻來解釋 Access/Refresh Token 的使用過程：

假設我在網上預定了一家酒店。如果要入住這家酒店，我必須出示身份相關信息和訂單。酒店前臺會登記相關信息和訂單信息，確認無誤后會給我一張票據和一張房卡（票據記錄我需要入住多少天，而房卡則讓我有當天的入住權）。以上場景中，“身份相關信息和訂單”是我的用戶名密碼，“票據/房卡”是Refresh/Access Token，“前臺”是認證服務器，“房間”是資源服務器。

在整個入住過程中，“身份相關信息和訂單”只在前臺使用一次；實際能進入房間的是“房卡”，但是房卡只有一天的有效期；如果房卡過期，我需要憑“票據”去前臺刷新“房卡”，獲取第二天的入住權。將Token拆分成兩個，就是為了解決安全性和用戶體驗方面的矛盾——

• Access Token使用頻繁，且與用戶數據直接關聯，安全性方面比較敏感，因此有效期設置得較短，即使Access Token泄漏也將很快失效。利用過期時間較短這個特性，也可以及時更新用戶的訪問權限（比如管理員縮小了的某員工訪問公司數據的權限，當Token過期后換取的新Access Token將立馬縮小其訪問數據的權限）。

• 而 Refresh Token僅用于獲取新的Access Token，使用頻率較低，不與用戶數據直接關聯，過期時間允許設置得長一些。這樣就解決了用戶反復登錄的問題。

實現對用戶會話的管理

站在系統管理員的角度，我們很容易想到去管理用戶的會話行為。一般來說，可以通過設置Token過期時間、設置結束會話的行為、手動結束用戶會話這三種方式來管理用戶會話。目前玉符IDaaS在Token標準應用的基礎上，為管理員開放了自定義會話管理的功能，在提升系統管理員的運維體驗上更進一步——讓管理員真正“有能力管理”系統發放出去的Token，比如：會話過期時間設置（如圖3）：

圖 3結束會話行為設置（如圖4）：

圖 4手動結束用戶會話（如圖 5）：

圖 5

綜上所述，通過 Access Token 和 Refresh Token 配套使用，我們得以很好的平衡 Token 時效性（安全性）與用戶體驗二者之間的關系，并利用 Refresh Token 的特點讓 IT 系統管理員真正有能力管理系統發放出去的Token，并實現“點對點”的結束會話操作。IDaaS（Identity as a Service）即身份認證管理云平臺，它能提供多種標準化功能幫助用戶實現高效、安全的身份認證管理服務，如單點登錄、智能多因素認證、賬號生命周期管理等等。

看完上述內容，你們對如何平衡Token安全性和用戶體驗有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。