瞭解JWT

Question

我已經花了幾個星期的時間試圖圍繞JWT對象包裹頭部。前提是有道理的，但我感到困惑的地方是安全方面。如果我是一個Javascript客戶端（例如Firebase）並且想要使用Open Auth向api發送安全請求，我會使用密鑰加密我的消息。但是，由於可能會查看客戶端來源，因此如何保護我的密鑰以免惡意請求無法通過。我錯過了什麼。有沒有辦法保護鑰匙？

Answer 1

使用收件人的公鑰執行加密過程。 您的客戶沒有私鑰可以生成和管理。

如果你想接收和解密這樣的智威湯遜，那麼你的客戶端必須創建一個密鑰對（私人和公共）僅用於會話，然後交換與服務器的公鑰。

Answer 2

喬爾，我覺得你有方向錯了;）

人們會使用JWT OAuth協議內實現一些人可能會稱之爲「Stateless Authentication」，這意味着auth服務器會發出一個簽名令牌（用於例如客戶端應用程序或用戶）在成功驗證（客戶端或用戶的）身份之後不存儲關於/的信息，這在使用不透明的令牌時將是必需的。

您的JS客戶端可以使用已簽名的令牌來根據JWT的內容（權利要求），調用某個REST API端點（在所謂的資源服務器上）來驗證令牌的簽名並授權您的請求。

您的客戶端應用程序以及資源服務器都能夠反省令牌並驗證其簽名，因爲它們或者與auth服務器有共享密鑰（誰使用該密鑰首先對令牌進行簽名）或者知道與Auth服務器用來簽署令牌的私鑰對應的公鑰（如Florent在他的評論中提到的那樣）。

JWTs也可以被加密，如果資源服務器或auth服務器要求的敏感信息，但不希望存儲/訪問的數據是有用的。只要您沒有使用過的加密密碼，您就無法對其進行反思。

......長話短說，OAuth協議描述了針對資源或auth服務器的客戶端身份驗證。 JWT可以用來傳送授權證書（作爲授權頭中的一個不記名令牌）。但是，在OAuth流程中使用JWT的想法並不是「向api發送安全請求」。

Answer 3

當構建API服務器，我更喜歡客戶端做自己的服務器上的加密過程，之後發送加密的數據。一切都在https下。

如果加密在某種程度上必須在Web客戶端完成，我更喜歡這個密鑰的壽命非常短暫，並且api服務器和客戶端都有一致的特殊算法來再次生成該密鑰。因此，如果密鑰被攻擊了，攻擊者無法長期受益。