我已經閱讀了一段時間，但沒有任何意義，解釋相互矛盾，評論證明了這一點。
到目前為止，我的理解是 JWT 存盤由服務器編碼的資訊，可能有到期時間，如果資訊有效，服務器及其密鑰可以解碼其中的資訊。說得通。
它對于可擴展性很有用，因此獨立的 API 可以解碼和驗證令牌中的資訊，只要它們擁有密鑰即可。此外，不需要將資訊存盤在任何資料庫中，不像在會話中。說得通。
如果令牌被盜，API 無法判斷令牌是否被正確的人使用。這是上面的缺點。
通過減少令牌的到期時間，可以減少安全漏洞，使竊賊有更少的時間在未經許可的情況下使用令牌。（附帶問題，但如果他們能夠偷一次，他們可能也會第二次偷）
但是減少令牌有效期的時間意味著每次令牌到期時用戶都需要登錄，并且從上面來看，它非常頻繁，因此不會提供太好的用戶體驗。說得通。
從現在開始，沒有任何意義：
引入重繪 令牌可以解決這個問題，因為它有更長的到期時間。使用重繪 令牌可以生成訪問令牌，因此用戶只要擁有重繪 令牌就可以登錄 - 這是更長的時間 - 而被盜的訪問令牌仍然只在短時間內有效。
對我來說，以上似乎是一個額外的復雜層，但沒有任何安全性改進。即對我來說，上面似乎等于一個長期存在的訪問令牌。
為什么？因為對我來說，重繪 令牌似乎基本上是一個訪問令牌（因為這就是它生成的）。因此擁有重繪 令牌意味著無限制的訪問令牌，因此無限制地訪問 API。
然后我讀了一個答案，說重繪 令牌和訪問令牌是一對一的映射，因此竊取訪問令牌仍然意味著未經授權訪問 API，但時間很短，并且竊取重繪 令牌會生成不同的訪問令牌，因此 API 可以檢測例外（同一帳戶使用不同的訪問令牌），從而使訪問令牌無效。
似乎我不是唯一一個對這個問題感到困惑的人。
如果上述情況不正確，重繪 令牌如何真正有幫助？
如果上述情況屬實，并且確實存在重繪 令牌和訪問令牌的一對一映射：
- 它完全失去了“無國籍”的好處
- 用戶無法從多個設備登錄（這將是一個“例外”）
- 我無法理解訪問令牌是如何失效的 - 令牌資料中是否存盤了會話 ID，或者用戶被“阻止”了？
如果有人能把問題說清楚就太好了，因為從 5 個解釋中，有 5 個相互矛盾的陳述（有時相同的解釋包含相互矛盾的資訊），而且許多開發人員都想了解這種方法。
uj5u.com熱心網友回復：
基于令牌的身份驗證存在這種普遍的混淆，所以讓我們嘗試清除其中的一些。
首先，JWT 不僅僅是由服務器“編碼”，它們被“簽名”（更準確地說，通常是訊息身份驗證）。目的是這樣的令牌不能被客戶端更改或更改，令牌中的任何欄位（宣告）都可以被信任為發行者創建的，否則驗證將失敗。
這產生了兩個重要的結論：
- 驗證令牌在任何實作中都很重要（顯然）
- JWT 的內容（宣告）未加密，即。這不是秘密，可以被客戶查看
如果這樣的令牌包含主題的某種身份（用戶，如用戶 ID 或電子郵件地址）和到期時間，則可以使用這樣的令牌來維護沒有服務器端狀態的會話。
另一個重要的收獲：
- 無法以無狀態方式注銷（立即會話失效），這是一個缺點。為了能夠在使現有會話無效時注銷，服務器必須存盤和檢查撤銷的令牌，這必然是一個有狀態的操作。
此外，JWT 令牌通常以客戶端代碼 (javascript) 可訪問的方式存盤，因此客戶端應用程式可以讀取用戶是誰以及令牌何時到期等資訊。不一定如此，但大多數實作都是這樣做的，例如。將其存盤在本地存盤中。這使得這些令牌容易受到 XSS 攻擊，這意味著任何成功的 XSS 都將能夠獲得令牌。
出于目前討論的原因，JWT 身份驗證本質上不如普通的舊會話安全，只有在需要時才應使用。很多時候使用token auth的時候，其實并不是必須的，只是花哨而已。
有時，這樣的令牌存盤在 httpOnly cookie 中，但在這種情況下，令牌不能發送到多個來源（localStorage 的一個好處），也可以使用普通的舊會話 ID，實際上會更安全。
好的，那么什么是重繪 令牌。正如您正確指出的，限制訪問令牌的生命周期對于限制受損令牌的有效性很有用。因此，當舊的訪問令牌過期時，重繪 令牌可用于獲取新的訪問令牌。關鍵是這些東西存放在哪里。
一個關鍵要點：
- 如果重繪 令牌的存盤方式與訪問令牌相同，則通常沒有任何意義。這是實作中的常見錯誤。
在更好的架構中，可能會發生以下情況：
- 至少有兩個獨立的組件（無論是邏輯上還是“物理上”在當今的云世界中都有意義）：身份提供者（IdP，或“登錄服務”）和資源服務器（例如 API）。
- 當用戶登錄時，他們實際上創建了與 IdP 的會話。在這種情況下，會為 IdP 源（域名）設定一個普通的舊會話 ID（充當重繪 令牌）或實際的 JWT 重繪 令牌。
- 然后在資源服務器源需要時使用與身份提供者的現有會話創建訪問令牌。
- 現在即使資源服務器完全被攻陷，比如在成功的 XSS 的情況下，重繪 令牌屬于一個完全獨立的來源，因此無法被攻擊者訪問。即使它是相同的來源，但重繪 令牌在 httpOnly cookie 中，這也有幫助，因為攻擊者需要能夠對受害用戶執行重復的 XSS 以接收新的訪問令牌。
可以有這方面的實作變體，但重點是上述，分離對兩個令牌的訪問。
我認為將重繪 令牌一對一映射到訪問令牌是不尋常的，也是不必要的，但實際上有時需要每個用戶一個會話（尤其是在金融應用程式中，您希望進行非常清晰的審計）用戶做了什么）。但這與上面討論的事情沒有太大關系。
同樣如上所述，以無狀態方式無法正確注銷（會話失效）。幸運的是，實際上很少有應用程式需要在服務器端真正實作無狀態。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/346392.html
上一篇：使用php注冊后自動登錄