選擇存儲更多的是權衡，而不是試圖找到明確的最佳選擇 . 我們來看幾個選項：

選項1 - Web存儲(localStorage或sessionStorage)

優點

瀏覽器不會自動包含從Web存儲到HTTP請求的任何內容，使其容易受到CSRF的影響

只能通過在創建數據的完全相同的域中運行的Javascript來訪問

允許使用最語義正確的方法在HTTP中傳遞令牌身份驗證憑據(帶有 Bearer 方案的 Authorization 標頭)

很容易挑選應該包含身份驗證的請求

缺點

無法通過在創建數據的子域中運行的Javascript訪問_( example.com 無法讀取 example.com 所寫的值)

??易受XSS攻擊

為了執行經過身份驗證的請求，您只能使用允許自定義請求的瀏覽器/庫API(在 Authorization 標頭中傳遞令牌)

用法

您可以利用瀏覽器localStorage或sessionStorage API在執行請求時存儲然后檢索令牌 .

localStorage.setItem('token', 'asY-x34SfYPk'); // write

console.log(localStorage.getItem('token')); // read

選項2 - 僅HTTP的cookie

優點

這是 not 易受XSS攻擊

瀏覽器會自動在滿足cookie規范的任何請求中包含令牌(域，路徑和生命周期)

可以在頂級域創建cookie，并將其用于子域執行的請求

缺點

??它容易受到CSRF的影響

您需要注意并始終考慮子域中cookie的可能用途

Cherry挑選應該包含cookie的請求是可行但更麻煩

您可能(仍然)遇到一些問題，瀏覽器處理cookie的方式差異很小

??如果您不小心，可以實施易受XSS攻擊的CSRF緩解策略

服務器端需要驗證cookie以進行身份驗證，而不是更合適的 Authorization 標頭

用法

您無需在客戶端執行任何操作，因為瀏覽器會自動為您處理任何事情 .

選項3 - 服務器端忽略Javascript可訪問的cookie

優點

這是 not 易受CSRF攻擊( because it's ignored by the server )

可以在頂級域創建cookie，并將其用于子域執行的請求

允許使用最語義正確的方法在HTTP中傳遞令牌身份驗證憑據(帶有 Bearer 方案的 Authorization 標頭)

櫻桃挑選應該包含身份驗證的請求有點容易

缺點

??它容易受到XSS的攻擊

如果您不小心設置cookie的路徑，那么瀏覽器會在請求中自動包含cookie，這將增加不必要的開銷

為了執行經過身份驗證的請求，您只能使用允許自定義請求的瀏覽器/庫API(在 Authorization 標頭中傳遞令牌)

用法

您可以利用瀏覽器document.cookie API在執行請求時存儲然后檢索令牌 . 此API不像Web存儲那樣精細(你得到了所有的cookie)所以你需要額外的工作來解析你需要的信息 .

document.cookie = "token=asY-x34SfYPk"; // write

console.log(document.cookie); // read

附加說明

這似乎是一個奇怪的選擇，但它確實有一個很好的好處，你可以讓存儲可用于頂級域和所有子域，這是Web存儲不會給你的東西 . 但是，實施起來更復雜 .

結論 - 最終說明

我的 recommendation for most common scenarios would be to go with Option 1 ，主要是因為：

如果您創建Web應用程序，則需要處理XSS;始終，獨立于您存儲令牌的位置

如果你不想擔心的話

另請注意，基于cookie的選項也大不相同，因為選項3 cookie僅用作存儲機制，因此它幾乎就像是客戶端的實現細節 . 但是，備選方案2意味著更傳統的處理身份驗證的方式;有關此cookie與令牌的進一步閱讀，您可能會發現這篇文章很有趣：Cookies vs Tokens: The Definitive Guide .

最后，沒有一個選項提到它，但當然必須使用HTTPS，這意味著應該適當地創建cookie以考慮到這一點 .

總結

以上是生活随笔為你收集整理的浏览器中java在什么位置,在基于浏览器的应用程序中保存JWT的位置以及如何使用它...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。