爲什麼我應該讓JSON Web Token負載不加密？

Question

我在閱讀JWT，有太多的教程和很多方法，這很令人困惑。

我有幾個關於JWTs的正確使用問題：

1）我總是看到運送JWTs並從服務器不一致的手段。 For example, here：用於檢索標記的一種傳輸方法（通過POST主體中的JSON編碼對象），另一種用於提交它的方法（通過HTTP標頭）。爲什麼這種不一致？當然，這取決於實施者選擇方法，但至少要保持一致並且只使用標題或僅使用正文，這不是好的做法嗎？

2）JWT負載包含狀態信息，因爲服務器沒有維護它。很明顯，應該將有效負載的大小盡可能小，因爲JWT的大小會被添加到每個請求和響應中。也許只是一個用戶ID和緩存的權限。當客戶端需要任何信息時，它可以通過（通常是JSON編碼的）HTTP主體接收它並將其存儲在本地存儲中，似乎不需要爲同一目的訪問只讀JWT有效負載。那麼，爲什麼要保持JWT有效載荷不加密呢？爲什麼要混合使用兩種方式獲取應用程序數據給客戶端，並同時使用JWT有效內容和正常的響應式數據體？最佳做法不應該保持JWT始終加密嗎？無論如何，它只能在服務器端進行更新。

Answer 1

1）我一直看到不一致的方式將JWT傳輸到服務器和從服務器傳輸。至少要保持一致並且只使用標題或僅使用正文，這不是一種好的做法嗎？

這可能取決於客戶端。雖然通過將JWT存儲在cookie存儲中，Web應用程序可以獲得更高的安全性，但本地應用程序可能會優先考慮本地存儲以訪問JWT信息。 [1]

2）JWT負載包含狀態信息，因爲服務器沒有維護它。很明顯，應該將有效負載的大小盡可能小，因爲JWT的大小會被添加到每個請求和響應中。也許只是一個用戶ID和緩存的權限。當客戶端需要任何信息時，它可以通過（通常是JSON編碼的）HTTP主體接收它並將其存儲在本地存儲中，似乎不需要爲同一目的訪問只讀JWT有效負載。

JWT保留後端狀態，而不是客戶端狀態。後端狀態可能是User 128 is logged in as administrator。這是（在我的例子中）存儲在智威湯遜的Subject和Scopes。客戶端不會發送包含此信息的後端會話的ID，而是直接在JWT中提供信息。後端因此不必保持存儲用戶128的logged in state的會話。如果客戶端請求信息User 2，則BE可以判定如果JWT告知登錄的用戶具有ID 1，則該信息被禁止。

那麼，爲什麼要保持JWT有效載荷不加密呢？

該狀態通常對客戶不是祕密。客戶端不能相信JWT中的信息，因爲它無法訪問用於驗證JWT的密鑰，但它仍然可以根據JWT中的信息調整GUI等。 （就像顯示管理GUI的按鈕一樣。）

爲什麼要將應用程序數據的兩種獲取方式混合到客戶端並同時使用JWT有效內容和正常的數據回覆體？

參見上文，JWT的主要目的是將信息保留在後端而非客戶端。一旦用戶登錄，後端詢問：「嘿，你能爲我保存這個信息並將它附加到每個請求中，以便我可以在此期間忘記你嗎？」就像你的經理要求你在你的裙子上戴上名字貼紙，這樣他/她不必記住你的名字。 :-)（他/她簽署它，這樣你不能改變它沒有他/她注意到。

應該不是最好的做法是保持JWT始終處於加密狀態？它只能在服務器端進行更新

它並沒有真正帶來任何安全性，除非你在JWT中存儲祕密信息，並且該托架更適合做服務器端解密與僅僅驗證簽名相比更加麻煩。

[1] Local Storage vs Cookies