我正在慢慢掌握使用微服務進行身份驗證的技巧，但遇到了一個相當基本的問題。我假設的架構如下，一個auth微服務，處理注冊、登錄、令牌重繪 ，一個TODOS微服務處理用戶的待辦事項。
我想在重繪 令牌旁邊使用短暫的 JWT。
如何使用重繪 令牌？由于 JWT 的過期時間如此之快（幾分鐘），我todos是否auth向重繪 然后再次以某種方式呼叫API？我是否在客戶端上進行池化并定期檢查 JWT 是否已過期？
這些是我的一些問題，但基本上可以歸結為
- 如何處理 JWT 過期？（在 API 呼叫期間和空閑時）
- 我是否回傳 JWT 已過期或僅 403 的特定錯誤？
- 如何處理這些往返（如果這是要走的路），在獲得 403，然后進行身份驗證以重繪 然后回傳呼叫之間？
uj5u.com熱心網友回復：
因此，您的呼叫者擁有訪問令牌和重繪 令牌。
當呼叫者想要呼叫 api 時，他們將使用訪問令牌。接收者將驗證訪問令牌（包括過期），如果訪問令牌不再有效，將回答“訪問被拒絕”。
當客戶端被拒絕訪問時，他們使用重繪 令牌來獲取新的訪問令牌。
問題是為什么需要重繪 令牌？正如你所說 - 訪問令牌是短暫的。為什么這樣？創建訪問令牌后，每個資源/api 都可以對其進行驗證。但是沒有辦法撤銷訪問令牌（帶有撤銷串列的選項很難正確實作）；因此，我們使用短期訪問令牌而不是撤銷。
由于訪問令牌的壽命很短，如果他們不斷要求批準另一個令牌，這將是一個糟糕的客戶體驗；如果使用訪問令牌代表客戶做一些事情，這是不可能的。為了解決這個問題，我們有重繪 令牌。重繪 令牌用于獲取新的訪問令牌。
使用重繪 令牌的最重要屬性：這是令牌提供者有機會撤銷訪問權限的時刻 - 提供者可能決定此重繪 令牌不再有效，例如因為客戶決定停止訪問。
對于你的問題：
- 如何處理 JWT 過期？（在 API 呼叫期間和空閑時）
您使用訪問令牌呼叫 api，如果訪問被拒絕，則使用重繪 令牌來獲取新的訪問令牌。這是最簡單的方法。作為替代方案，您可以使用后端作業在訪問令牌過期時重繪 它們。這顯然更復雜。
- 我是否回傳 JWT 已過期或僅 403 的特定錯誤？
我不會。如果訪問被拒絕，則被拒絕。
- 如何處理這些往返（如果這是要走的路），在獲得 403，然后進行身份驗證以重繪 然后回傳呼叫之間？
不知道你是什么意思。我的代碼（在這個用例中）有一個簡單的句柄——如果訪問被拒絕，那么使用重繪 令牌來獲取新的訪問令牌；然后快取訪問令牌。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/456379.html