---
tags: Blue 的學習紀錄
---

# JWT 放在 cookie 或是 bearer token？

這個問題的緣由來自於網路上網友的提問
而我曾經也思考過這問題，但是沒有做紀錄

以下的內容是我與匿名網友的問答過程
（未來若我有想到額外事情，可能會再補充）

網友1：
> 請問巨佬們, 關於 JWT 哪時候該放 cookies 又哪時候該用 bearer token 呢

我：
> 我分享自己在不查資料下的直覺認知，有錯請幫我指正~
> cookie：
放在 cookie 的資料是由瀏覽器自動帶上的
所以前端實作上不用管理 JWT 的存放，由瀏覽器來負責
但同時可能需要防範 CSRF 攻擊的可能，所以可能需要實作 CSRF token 的機制
> header bearer token：
由前端在 request header 中手動放入 JWT
因為是手動，所以前端需要實作"放置"的邏輯
而不像 cookie 是由瀏覽器自動帶上
而且前端也需要負責和決定 JWT 的存放
例如放在 local storage？
還是單純用變數存起來，分頁關掉後就不見？等等
> 結論：
使用 cookie 表示選擇讓瀏覽器自動化做掉一些事
工程師在使用 cookie 以前應先了解瀏覽器怎麼處理 cookie
使用 bearer token 表示前端要負責 JWT 的傳送及存放
由於是工程師手動做，所以實作門檻相較於 cookie 較高一些，但也比較自由

網友2：
> 補充另一個角度來區分這兩個方法的差異：cookie 需要同網域，需要防 CSRF；bearer token 需要 local storage，需要防 XSS。
> 因此同網域的話，用 cookie 會比較好，比較多安全的參數可以調整
如 samesite、httponly、secure 等，跨網域只能（或建議）選擇用 bearer token。

網友1：
> 太棒了!
不過是不是用 cookies 就沒辦法同時兼顧到 mobile 端的部份呢 (IOS/Android 本身好像沒 cookies 機制)

網友2：
> 嗯對，除非自己寫程式模擬瀏覽器行為

## 延伸閱讀

[更好的選擇？用 JWT 取代 Session 的風險](https://blog.kenwsc.com/posts/2023/jwt-vs-session/)

# refresh token 交換 access token 這件事情的觸發時機

懶得開新篇，所以在這裡做紀錄
形式一樣和上面那篇一樣，是紀錄與網友間的互動問答

網友1：
> 請問通常 refresh token 交換 access token 這件事情的觸發時機
前端會怎麼去設定呢
因為要保證 refresh token 到期之前
一直持有有效的 access token
好奇怎麼做比較對

網友2：
> 你這個系統設計問題 去找AAA system design
這就有答案了
很common的設計
有系統瓶頸再提出來 否則你這個問題太base了

我：
> 雖然我是純後端，不熟這 part，但再來拋磚引玉看看XD
我的想法是前端收到401後
就去拿refresh token （如果有的話）更新 access token
然後 retry 一次
retry後還是401就當作沒權限去處理

網友3：
> 比較正規的做法是，每個 access token 都有自己的 expire time，通常在過一半的時間做 refresh，如果可以排程就是先排好時間做 refresh，如果不行就是在 startup 的時候判斷時間是否剩一半不到，如果是就做 refresh，實務上是兩者都會做，避免系統把排程清掉

網友4：
> 到 auth server login 後取得 AT1 跟 RT1
用 AT1 去取得資料
當 AT1 過期去取資料失敗後
拿 RT1 再去 auth server 再要一組 AT2 跟 RT2
Loop

網友5：
> access token 過期的時候再拿 refrest token 交換

網友4：
> 然後安全性部分
AT 要設定時效性，例如半小時後過期
RT 可以不用設時效性 (不會過期)，但只能用一次
> 如果發現同一個RT被重複使用，就整個都斷開！
斷開鎖鏈！（Ｘ