我正在為使用 JWT 進行身份驗證的站點創建 Web 服務器。由于一旦準備好這將是一個公開可用的系統，我想知道以下使用 JWT 訪問和重繪 令牌的身份驗證流程是否可以被認為是安全的。在這種情況下，假設一臺服務器同時提供身份驗證 API 和資源
當服務器啟動時，它將生成一個“運行 ID”，即當前 UNIX 時間戳和隨機字符/UUID。這存盤在記憶體中，任何重新啟動都會生成一個新的。
用戶在登錄或注冊時獲得初始 HttpOnly 訪問和重繪 令牌。訪問令牌的壽命較短（約 5 分鐘），而重繪 令牌的壽命較長（約 2 小時）。
訪問令牌的功能與正常一樣，并包含用戶 ID。重繪 令牌有用戶ID、服務器的運行ID和它自己唯一的“令牌ID”（類似于運行ID，每個重繪 令牌都是唯一的）
如果滿足以下條件，則在呼叫需要授權的端點時，會生成新的訪問和重繪 令牌，而不是用戶呼叫令牌重繪 端點：
- 訪問令牌已過期
- 重繪 令牌尚未過期
- 重繪 令牌中的運行 ID 與當前運行 ID 匹配
- 重繪 令牌的令牌 ID 未列入黑名單
如果運行 ID 不匹配或令牌 ID 已被列入黑名單，則重繪 令牌會立即被視為無效。令牌 ID 黑名單作為帶有 ID 和過期時間的陣列存盤在記憶體中（如運行 ID）。這允許用戶注銷并將使用該特定重繪 令牌列入黑名單。這也允許任何系統管理員通過重新啟動服務器來緊急使所有重繪 令牌無效，因為 runID 將更改。
我想知道這是否可以被視為安全的身份驗證流程
uj5u.com熱心網友回復：
我花了一段時間才了解代幣的情況以及您圍繞它的動機。我相信你在這里所做的比現實需要的更復雜，應該沒有理由引入這種復雜程度。另請注意，安全的定義是一把雙刃劍。這是完整性和機密性與可用性之間的永恒沖突。如果由于某種原因我們破壞了系統的可用性，那么在同樣的意義上它就不會被認為是安全的，關閉計算機不被認為是安全問題的解決方案。
話雖如此，讓我們看看你的解決方案。
您打算使用訪問和重繪 JWT 令牌。在這樣的系統中注銷應該是什么樣子？好吧，您只是忘記了客戶端的令牌資訊，或者如果您想在 cookie 中保存令牌 - 我相信您希望基于“HttpOnly”標志擁有 - 您可以清理 cookie。就是這個。一旦資訊從客戶端消失，令牌就不能輕易地重新創建。無需將服務器上的令牌列入黑名單。“忘記”他不使用的令牌符合客戶的最大利益，一旦令牌消失，就沒有第二個副本可以替換它。
如果我們想要處理實時用戶帳戶鎖定等場景，我們會使用令牌黑名單。如果你問我，這是一件昂貴的事情。
您仍然可以嘗試將重繪 令牌列入黑名單，但假設您的身份驗證機制可以訪問用戶池，如果用戶被鎖定，它可以簡單地檢查資料庫，無需在此處快取任何內容。
接下來我注意到的是，您在這里所做的重新組裝了非常簡單的 Http 會話處理，包括在服務器重新啟動后丟失會話。為什么不忘記令牌并使用簡單的會話呢？
我還想知道，為什么您打算只擁有一個系統實體。在高可用性時代和使用 JWT 令牌時，將身份驗證模塊與邏輯分開并擁有兩個以上的實體是完全有意義的。
另請注意，在他們查看您的代碼、配置和理想情況下的作業系統之前，沒有人能夠告訴您您所做的是否安全。有許多小塊可以破壞解決方案。理想情況下，請查看此處提供的 OWASP ASVS（應用程式安全驗證標準），了解兔子洞有多深。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/496366.html
標籤：javascript 节点.js 表示 安全 jwt