如何在使用JWT時保持共享機密的祕密，例如？

有一些非常基本的我不明白。爲了JWT的安全，客戶端和服務器必須共享一個祕密。如何在使用JWT時保持共享機密的祕密，例如？

但是，客戶端通常是在某個遠程完全未知的客戶端計算機上的瀏覽器中運行的JavaScript應用程序。

假設我是服務器和客戶端代碼的作者，我應該如何確保客戶端共享密鑰的安全？

來源

2016-08-18 mark

您是否在談論用於構建JWT的密鑰？因爲這不是發送給客戶... – Blakethepatton

這可能是我最喜歡的文章之一（與picto）http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-會話 - 第2部分 - 爲什麼你的解決方案不工作/ – Derek

你認爲祕密是共享的。它不一定是。（而且它只能在彼此信任的系統之間共享，你通常不能相信執行你的JavaScript的客戶端。）

JWT的典型用法是服務器使用祕密產生簽名數據併發送簽名數據（沒有祕密）在某處（例如客戶端）而沒有堅持它。當它獲取數據時，它可以驗證（使用祕密而不是持久的數據副本），因爲數據已被簽名，所以數據未被篡改。

該使用模式有哪些應用？你可以例如以這種方式實施基於令牌的權限，從而進行身份驗證，而無需標識：

讓我們假設您提供了雲存儲服務。用戶可以上傳文件，併爲其指定一些標識符，比如5。您生成一個包含JWT簽名數據的可共享URL「可以訪問文件＃5」作爲其參數之一併將該URL顯示給用戶。用戶以及他們與之分享的每個人都可以通過該URL訪問該文件。您只需驗證簽名是由您創建的有效簽名，並且簽名數據表示正確的文件。當然，如果與用戶共享URL的用戶進一步分發，其他人也可能以這種方式訪問。但沒有URL的知識，該文件不可訪問。

來源

2016-08-18 20:23:00

因此，JWT是爲服務器在來自同一用戶的HTTP請求之間「保留」一些有限的狀態。只有服務器知道這個祕密。對？ – mark

是的，儘管它不限於HTTP請求。您可以通過簽署包含用戶標識和電子郵件地址的對象來實現電子郵件地址驗證，將結果打包到URL中並將該URL發送到電子郵件地址。當這樣的URL被調用並且簽名是有效的（根據你的祕密），那麼你知道電子郵件到達並且確認鏈接被點擊。 –

「祕密保存在發送者和接收者」 - https://jwt.io/introduction/教程視頻（2:05）。所以我還是不明白如何保留髮件人（Javascript）的祕密部分。 – Osi

這與在驗證碼上將cookie發送給客戶端然後依靠其進行其他操作相同。

是的，你不能確保客戶的餅乾安全，他們可以被盜。和jwt令牌一樣可以被盜取。

關於jwt的一個好的部分是，令牌本身並不是cookie的通信部分，所以即使在http通信中你也可以使用它 - 即使有人獲得了用戶請求的有效載荷或頭部，他也不能創建新的請求與其他數據，這是可能的情況下使用Cookie。

來源

2016-08-18 20:25:16

我不明白。它不是通信的一部分，而是通信的一部分，作爲授權標頭中的承載令牌。最終結果是相同的 - 服務器通過來自同一用戶的HTTP請求「保留」某種狀態。它與cookie有什麼不同？我必須在這裏錯過一些東西。 – mark

那麼，當然，jwt令牌是_when_用戶收到它的通信的一部分。但是，在用戶向服務器發送有效載荷和簽名之後，_not_令牌本身與cookie一樣。 –

但是爲了驗證簽名，服務器需要相應的JWT的頭部和有效載荷部分。由於它們沒有到達網絡，因此服務器需要從數據庫中存儲和獲取它們。如果是這樣，那麼這是會話管理。我認爲智威湯遜可以消除對會話管理的需求。再次，我必須錯過一些東西。 – mark

如何在使用JWT時保持共享機密的祕密，例如？

回答

相關問題