認識一下 Cookie、Session、Token 在實際中的應用

引言

提到用戶登陸態這個問題，不免就會說起 Cookie、Session、Token 等三個知識點。因此，今天就略微總結一下這三者在這個場景下的應用。

1、Cookie

我想做爲一個前端，對上述的三者中，最熟悉的就是 Cookie 了。由於前端能夠本身操做 Cookie，而後實現本身想要的需求。不過，在不少時候，千萬注意不要用 Cookie 存儲一些隱私信息，由於一旦被 XSS （腳本注入）就 GG。

回到正題，Cookie 在須要記錄用戶登陸態的場景下，並非前端直接存儲用戶信息，而是在第一次請求登陸時，後端將這個用戶的信息存儲在 Cookie 中（能夠設置有效時間、域名等等），而且在響應頭中一塊兒發送給前端，而後前端在以後的請求中，都會在請求報文中攜帶這個 Cookie （攜帶的過程，是瀏覽器自動判斷後端是否在響應報文中存在 Set-Cookie，存在則一樣會在以後的請求報文中攜帶 Set-Cookie），因此以後，服務端判斷是否存在這個 Cookie ，存在則直接讀取響應的用戶信息，不存在則進行登陸操做。從而，完成整個的登陸狀態的記錄。

須要注意的是，後端在 Set-Cookie 的時候，必定要設置這個 Cookie 爲 http-only，即這個 Cookie 只能被 HTTP 協議讀取，禁止前端以任何方式讀取。

2、Session

對於 Session 這個名稱，若是沒有了解過的同窗可能會一臉懵。相比較 Cookie 是存儲在客戶端不一樣的是，Session 是存儲在後端的，具體的存儲方式，Session 通常是在 Tomcat、Jetty 等容器中進行管理。

一樣是記錄用戶登陸態，Session 也會用到 Cookie。不過不一樣於 Cookie 的是，以 Session 的方式記錄用戶登陸態，會將 用戶的信息存儲在 Session 中，而且會將 SessionId 塞到 Cookie 中，這個 Cookie 一樣會出如今響應報文中（一樣須要設置 http-only），以後發生的就和 Cookie 記錄登陸態的過程相似，只不過讀取用戶信息是根據 SessionId 來讀取對應的 Session 中的用戶信息。

3、Token

以 Token 形式記錄登陸態和 Cookie 記錄登陸態有點相似，可是不一樣的是，Token 並非直接存儲用戶信息，而是將用戶信息編碼後，經過響應報文傳給前端，以後每一次請求，請求報文中都會帶有這段編碼信息，後端經過解碼得到用戶信息，這個方法也被稱做 JWT（Json Web Token）。（因此 Token 適合分佈式微服務，即服務端不須要保存特定的用戶信息）

值得一提的是 JWT 是由三個部分組成： 1.Header，一般是一個 JSON 對象，用於描述 JWT ，例如

{
		"alg": "HS256",
		"typ": "JWT"
	}
複製代碼

alg 屬性表明進行加密的簽名的算法，默認是 HS256；type 表明這個令牌的類別。

2.Payload，是用於存放實際須要傳輸的數據，JWT 官方規定的字段以下：

iss: 簽發人
	exp：過時時間
	sub：主題
	aud：受衆
	nbf：生效時間
	iat：簽發時間
	jti：編號
複製代碼

你們可能會發現，沒有咱們實際須要的特定字段，JWT 也容許咱們自定一些字段（例如用戶名之類的）。

3.Signature，是用於對前面的兩部分的數據進行簽名，防止數據篡改。由服務端定義生成一個祕鑰，而後將這三個部分進行簽名算法加密，每一個部分經過 . 鏈接成一個字符串，經過響應報文發送給客戶端。