學習筆記 | 關於 Cookie、Session、Token

Onur Binay on Unsplash

延續先前的筆記，「網路請求」是瀏覽器和伺服器的溝通橋梁，目的是為了取得資料庫內的資源，除了 CORS 這種瀏覽器本身的阻擋機制，伺服器也會需要進行「身分驗證或授權」這道阻擋，並不是使用者有帶上 header 告知身分，就一定可以把資料 response 回來的。

像是最常見的會員資料，伺服器就必須確認你是會員本人，才會將你的訂單資訊、歷史訂單...等內容回傳過來，所以我們需要進行「登入」，告知伺服器：我就是會員本人啦

一般常見的身分驗證方式有以下三種：

1. 使用者應該知道的資訊 ex:密碼
2. 使用者持有的證件、憑證 ex:身分證、Token
3. 使用者的身體特徵 ex:指紋

很顯然的，一般我們使用的會員登入，驗證的是「使用者應該知道的資訊」，但總不能每次要查看購物車內的商品或歷史訂單，就要重新進行驗證吧，所以登入以後的請求，就會改用「使用者持有的證件」，也就是 Token 這項令牌了

我聽過一句話，「技術的發明，是為了解決問題」，所以了解 Token 以前，也需要知道它為什麼而誕生吧?

這就需要從身分驗證的狀態來說了，先定義一下此時的「狀態」所代表的意思是：

• 有狀態 ➜ 表示會保存關於使用者的信息、具有記憶性，能夠追蹤使用者的活動
• 無狀態 ➜ 表示對處理過的事件並沒有記憶性，每個請求都是獨立的，因此也無法辨識這次的請求和上次的請求是否為同一個人

最初瀏覽器和伺服器驗證身分後，是透過瀏覽器的 Cookie 紀錄使用者的狀態，並在後續訪問資料時，帶著 Cookie 儲存的狀態去進行請求

此時 Cookie 有很致命的問題是

1. 資料透明 ➜ 透明意味著完全公開，沒有任何加密動作，存在安全性問題

2. 網域限制 ➜ 無法跨網域共用 Cookie 所儲存的狀態訊息

因此開發者們轉而使用 Session 來記錄使用者狀態，Session 的存取方式基本上與 Cookie 相同，但狀態存取方改變為「伺服器」了

伺服器會將使用者狀態打包成一個 ID，並將這個 ID 回傳給瀏覽器，瀏覽器要訪問後續資源時，就帶這個 ID 進行驗證，解決了 Cookie 資料透明和只能存取字串的問題

然而 Session 也有存在其他的問題

1. 只要瀏覽器關閉就會失效

2. 狀態由伺服器存取，假設每次訪問到的伺服器不同，則伺服器之間又需要互相索取資料，消耗效能

因此 Token 就誕生啦！

Session 已經解決資料裸奔的問題， Token 要解決的則是「無狀態」的身分驗證問題

Token 會在使用者進行身分驗證後，由伺服器將使用者狀態打包加密，再傳送給瀏覽器，成為一種瀏覽器向伺服器訪問資料時的通行證，也可以稱為金鑰或令牌

此時伺服器不再需要保留使用者狀態，只要確認 Token 的時效性，就可以進行身分驗證，也可以進行跨域的請求啦！就相當於去遊樂園，只要持有一日票券的使用者，都可以使用遊樂設施，是認票不認人的～

本篇筆記參考 深入解析 JWT：了解 Token 的運作與應用 整理而成

我是Amber，前端學習中，歡迎交流討論🧸