學習筆記 | 關於 Cookie、Session、Token
延續先前的筆記，「網路請求」是瀏覽器和伺服器的溝通橋梁，目的是為了取得資料庫內的資源，除了 CORS 這種瀏覽器本身的阻擋機制，伺服器也會需要進行「身分驗證或授權」這道阻擋，並不是使用者有帶上 header 告知身分，就一定可以把資料 response 回來的。
像是最常見的會員資料，伺服器就必須確認你是會員本人，才會將你的訂單資訊、歷史訂單...等內容回傳過來，所以我們需要進行「登入」，告知伺服器：我就是會員本人啦
一般常見的身分驗證方式有以下三種：
- 使用者應該知道的資訊 ex:密碼
- 使用者持有的證件、憑證 ex:身分證、Token
- 使用者的身體特徵 ex:指紋
很顯然的，一般我們使用的會員登入，驗證的是「使用者應該知道的資訊」，但總不能每次要查看購物車內的商品或歷史訂單，就要重新進行驗證吧，所以登入以後的請求，就會改用「使用者持有的證件」，也就是 Token 這項令牌了
我聽過一句話，「技術的發明，是為了解決問題」，所以了解 Token 以前，也需要知道它為什麼而誕生吧?
這就需要從身分驗證的狀態來說了，先定義一下此時的「狀態」所代表的意思是：
- 有狀態 ➜ 表示會保存關於使用者的信息、具有記憶性，能夠追蹤使用者的活動
- 無狀態 ➜ 表示對處理過的事件並沒有記憶性，每個請求都是獨立的，因此也無法辨識這次的請求和上次的請求是否為同一個人
最初瀏覽器和伺服器驗證身分後，是透過瀏覽器的 Cookie 紀錄使用者的狀態，並在後續訪問資料時，帶著 Cookie 儲存的狀態去進行請求
此時 Cookie 有很致命的問題是
1. 資料透明 ➜ 透明意味著完全公開，沒有任何加密動作，存在安全性問題
2. 網域限制 ➜ 無法跨網域共用 Cookie 所儲存的狀態訊息
因此開發者們轉而使用 Session 來記錄使用者狀態，Session 的存取方式基本上與 Cookie 相同，但狀態存取方改變為「伺服器」了
伺服器會將使用者狀態打包成一個 ID，並將這個 ID 回傳給瀏覽器，瀏覽器要訪問後續資源時，就帶這個 ID 進行驗證，解決了 Cookie 資料透明和只能存取字串的問題
然而 Session 也有存在其他的問題
1. 只要瀏覽器關閉就會失效
- 狀態由伺服器存取，假設每次訪問到的伺服器不同，則伺服器之間又需要互相索取資料，消耗效能
因此 Token 就誕生啦！
Session 已經解決資料裸奔的問題， Token 要解決的則是「無狀態」的身分驗證問題
Token 會在使用者進行身分驗證後，由伺服器將使用者狀態打包加密，再傳送給瀏覽器，成為一種瀏覽器向伺服器訪問資料時的通行證，也可以稱為金鑰或令牌
此時伺服器不再需要保留使用者狀態，只要確認 Token 的時效性，就可以進行身分驗證，也可以進行跨域的請求啦！就相當於去遊樂園，只要持有一日票券的使用者，都可以使用遊樂設施，是認票不認人的～
本篇筆記參考 深入解析 JWT：了解 Token 的運作與應用 整理而成
我是Amber，前端學習中，歡迎交流討論🧸
你可能也想看
