Token作為用戶獲取受保護資源的憑證，必須設置一個過期時間，否則一次登錄便可永久使用，認證功能就失去了意義。但是矛盾在於：過期時間設置得太長，用戶數據的安全性將大打折扣；過期時間設置得太短，用戶就必須每隔一段時間重新登錄，以獲取新的憑證，這會極大挫傷用戶的積極性。針對這一問題，我們可以利用Access / Refresh Token這一概念來平衡Token安全性和用戶體驗。
Access / Refresh Token是什麼？
上圖表示Access/Refresh Token在客戶端、認證伺服器、資源伺服器三者之間的傳遞關係，簡單來說：
Access Token即「訪問令牌」，是客戶端向資源伺服器換取資源的憑證；Refresh Token即「刷新令牌」，是客戶端向認證伺服器換取Access Token的憑證。Access / Refresh Token如何使用？
上圖表示客戶端請求資源的過程中，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）：
結束會話行為設置（如圖4）
手動結束用戶會話（如圖 5）：
小結
綜上所述，通過 Access Token 和 Refresh Token 配套使用，我們得以很好的平衡 Token 時效性（安全性）與用戶體驗二者之間的關係，並利用 Refresh Token 的特點讓 IT 系統管理員真正有能力管理系統發放出去的Token，並實現「點對點」的結束會話操作。
以上回答來自我司研發工程師小龍馬。
IDaaS（Identity as a Service）即身份認證管理雲平臺，它能提供多種標準化功能幫助用戶實現高效、安全的身份認證管理服務，如單點登錄、智能多因素認證、帳號生命周期管理等等。由於 IDaaS 在國內尚屬於新興產品形態，很多人對它只有模糊的印象，所以我們計劃用一系列文章，深入淺出介紹 IDaaS 相關的技術原理和細節。本文是「IDaaS 技術解析系列」文章的第 2 篇。後續我們將繼續分享更多技術思考，歡迎關注本公眾號並留言交流。搜索「玉符科技」了解更多。