如何在客戶端層處理JWT？

Question

這是一個主觀的問題，盡管我認為這不是基於觀點的。 在這里提出問題的唯一原因是，即使閱讀了有關JWT身份驗證的多篇文章，我也找不到令人滿意的答案。

我最近開始學習JWT，發現它是由服務器頒發給客戶端的3部分令牌，用於真實性以及以聲明形式傳遞諸如用戶范圍/角色/權限等數據。

但是我的問題是：

1. 令牌的聲明部分仍然是base64編碼的字符串，可以使用atob/btoa輕松解析該字符串。 那么傳輸真的安全嗎？ 這里真正的收獲是什么？

2. 關於生成令牌並將令牌發送到UI有多篇文章。 但是，幾乎沒有關於UI到底如何使用它的好文章。 使用atob解碼令牌並使用其中的內容是一種常見的做法嗎？ 還是存在另一種驗證和檢索數據的方式。

3. 通過標頭傳輸數據真的安全嗎？ 我的意思是它可以安全抵御MITM，XSS等問題。

我真的很感謝專家為解決這些問題付出的努力？

Answer 1

對於問題1，收益不在客戶端。 如果您不信任從服務器收到的內容，則無論如何對其進行混淆/編碼/加密/，都將無法信任它。 關鍵是您將此令牌發送回服務器。 在服務器上，快速檢查將發現此令牌是合法的。 想象一下一個復雜的登錄場景，其中MegaCorp在739個子系統中查找用戶的權限，將其合並為一個有效負載，然后不必在進一步的請求上再次這樣做。 客戶端將令牌發回時，它會驗證您是否已正確登錄並使用權限進行進一步處理。

對於＃2，您可以將任何您喜歡的東西放入此有效負載中，只要它不是太安全即可。 我主要將其用於基本用戶信息和應用程序權限。 因此，我可以繪制用戶名並提供指向特定用戶設置頁面的鏈接。 我可以檢查用戶是否有權訪問管理頁面或需要檢查的任何權限。 盡管惡意用戶可以通過操縱客戶端數據來欺騙系統，因此可以看到管理頁面，但是當調用返回到服務器以獲取該頁面的數據時，令牌要么是非法的，要么是請求將被拒絕，或者它不包含適當的權限，再次，它將被拒絕。

我對安全性的了解還不足以嘗試回答＃3。

---

有些人只將JWT用於isLoggedIn ，這很好，但是我認為錯過了一些有用的可能性。 如果使用得當，這可以是捕獲客戶端和服務器的用戶信息的單一機制。 但是我認為重要的一面是服務器。 這可以在客戶端上以多種方式完成。 但是很難為服務器找到更好的東西。

Answer 2

令牌的聲明部分仍然是base64編碼的字符串，可以使用atob / btoa輕松解析該字符串。 那么傳輸真的安全嗎？ 這里真正的收獲是什么？

如果您通過https發送令牌，則傳輸是安全的（其他人無法讀取/修改）。 JWT包含兩個重要部分：有效負載和驗證簽名。 簽名只能由一個人生產和驗證，並證明有效載荷對該人是合法的。 這是一個簡單的用例：

1. 客戶端發送到Auth服務器的憑據才能獲得發布內容的權利
2. 服務器接收憑證並通過一個復雜的過程對其進行驗證，然后將JWT發送回客戶端，並說：{我授予客戶端發布簽名的Auths erver的權利}
3. 客戶端在本地存儲令牌
4. 當客戶端需要發布某些內容時，他發送JWT到服務器B，服務器B與Auth服務器共享簽名密鑰。
5. 服務器B輕松驗證令牌並發布客戶端的工作

用法的另一個示例是僅通過郵件進行身份驗證。

關於生成令牌並將令牌發送到UI有多篇文章。 但是，幾乎沒有關於UI到底如何使用它的好文章。 使用atob解碼令牌並使用其中的內容是一種常見的做法嗎？ 還是存在另一種驗證和檢索數據的方式。

通常，客戶端希望從某個服務器獲取令牌，以便稍后將其發送回去。 客戶端無法驗證簽名，因為他不與服務器共享私鑰，他不是信任源。

通過標頭傳輸數據真的安全嗎？ 我的意思是它可以安全抵御MITM，XSS等問題。

使用https是安全的： HTTPS標頭是否已加密？