大家好,我是前端dog君,一名95后前端小兵。2019年畢業(yè)于北京化工大學(xué),天津人,不知道有校友和老鄉(xiāng)嘛?對(duì)前端的熱愛(ài),讓我們?cè)诖讼嗑?,希望這篇文章,能幫助到您,也同時(shí)希望能交到志同道合的小伙伴,共同發(fā)展,一起進(jìn)步。我的微信號(hào)dm120225,備注簡(jiǎn)書(shū),期待您的光臨。
最近在公司整理權(quán)限相關(guān)的內(nèi)容,dog君所在公司項(xiàng)目有兩套架構(gòu):一套是前后端未分離,采用的是cookie + session的鑒權(quán)模式,一套是現(xiàn)有的前后端分離架構(gòu),采用的是token鑒權(quán)模式。正好趁著這個(gè)機(jī)會(huì)復(fù)習(xí)下cookie session 和token之間有什么區(qū)別。話(huà)不多說(shuō),讓我們開(kāi)始吧!
前言
無(wú)狀態(tài)的HTTP協(xié)議
很久很久之前, Web基本都是文檔的瀏覽而已。既然是瀏覽, 作為服務(wù)器, 不需要記錄在某一段時(shí)間里都瀏覽了什么文檔, 每次請(qǐng)求都是一個(gè)新的HTTP協(xié)議,就是請(qǐng)求加響應(yīng)。不用記錄誰(shuí)剛剛發(fā)了HTTP請(qǐng)求, 每次請(qǐng)求都是全新的。
如何管理會(huì)話(huà)
隨著交互式Web應(yīng)用的興起, 像在線(xiàn)購(gòu)物網(wǎng)站,需要登錄的網(wǎng)站等,馬上面臨一個(gè)問(wèn)題,就是要管理回話(huà),記住那些人登錄過(guò)系統(tǒng),哪些人往自己的購(gòu)物車(chē)中放商品,也就是說(shuō)我必須把每個(gè)人區(qū)分開(kāi)。
本文主要講解cookie,session, token 這三種是如何管理會(huì)話(huà)的;
cookie
cookie 是一個(gè)非常具體的東西,指的就是瀏覽器里面能永久存儲(chǔ)的一種數(shù)據(jù)。跟服務(wù)器沒(méi)啥關(guān)系,僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能。
cookie由服務(wù)器生成,發(fā)送給瀏覽器,瀏覽器把cookie以KV形式存儲(chǔ)到某個(gè)目錄下的文本文件中,下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶(hù)端上的,所以瀏覽器加入了一些限制確保cookie不會(huì)被惡意使用,同時(shí)不會(huì)占據(jù)太多磁盤(pán)空間。所以每個(gè)域的cookie數(shù)量是有限制的。
如何設(shè)置
客戶(hù)端設(shè)置
document.cookie = "name=xiaoming; age=12 "
- 客戶(hù)端可以設(shè)置cookie的一下選項(xiàng): expires, domain, path, secure(只有在https協(xié)議的網(wǎng)頁(yè)中, 客戶(hù)端設(shè)置secure類(lèi)型cookie才能生效), 但無(wú)法設(shè)置httpOnly選項(xiàng)
設(shè)置cookie => cookie被自動(dòng)添加到request header中 => 服務(wù)端接收到cookie
服務(wù)端設(shè)置
不管你是請(qǐng)求一個(gè)資源文件(如html/js/css/圖片), 還是發(fā)送一個(gè)ajax請(qǐng)求, 服務(wù)端都會(huì)返回response.而response header中有一項(xiàng)叫set-cookie, 是服務(wù)端專(zhuān)門(mén)用來(lái)設(shè)置cookie的;
- 一個(gè)set-cookie只能設(shè)置一個(gè)cookie, 當(dāng)你想設(shè)置多個(gè), 需要添加同樣多的
set-cookie - 服務(wù)端可以設(shè)置cookie的所有選項(xiàng): expires, domain, path, secure, HttpOnly
Cookie,SessionStorage,LocalStorage
HTML5提供了兩種本地存儲(chǔ)的方式 sessionStorage 和 localStorage;

session
什么是session
session從字面上講,就是會(huì)話(huà)。這個(gè)就類(lèi)似你和一個(gè)人交談,你怎么知道當(dāng)時(shí)和你交談的是張三而不是李四呢?對(duì)方肯定有某種特征(長(zhǎng)相等)表明他是張三;session也是類(lèi)似的道理,服務(wù)器要知道當(dāng)前請(qǐng)求發(fā)給自己的是誰(shuí)。為了做這種區(qū)分,服務(wù)器就是要給每個(gè)客戶(hù)端分配不同的"身份標(biāo)識(shí)",然后客戶(hù)端每次向服務(wù)器發(fā)請(qǐng)求的時(shí)候,都帶上這個(gè)”身份標(biāo)識(shí)“,服務(wù)器就知道這個(gè)請(qǐng)求來(lái)自與誰(shuí)了。至于客戶(hù)端怎么保存這個(gè)”身份標(biāo)識(shí)“,可以有很多方式,對(duì)于瀏覽器客戶(hù)端,大家都采用cookie的方式。
過(guò)程(服務(wù)端session + 客戶(hù)端 sessionId)

- 1.用戶(hù)向服務(wù)器發(fā)送用戶(hù)名和密碼
- 2.服務(wù)器驗(yàn)證通過(guò)后,在當(dāng)前對(duì)話(huà)(session)里面保存相關(guān)數(shù)據(jù),比如用戶(hù)角色, 登陸時(shí)間等;
- 3.服務(wù)器向用戶(hù)返回一個(gè)
session_id, 寫(xiě)入用戶(hù)的cookie - 4.用戶(hù)隨后的每一次請(qǐng)求, 都會(huì)通過(guò)
cookie, 將session_id傳回服務(wù)器 - 5.服務(wù)端收到
session_id, 找到前期保存的數(shù)據(jù), 由此得知用戶(hù)的身份
存在的問(wèn)題
擴(kuò)展性不好
單機(jī)當(dāng)然沒(méi)問(wèn)題, 如果是服務(wù)器集群, 或者是跨域的服務(wù)導(dǎo)向架構(gòu), 這就要求session數(shù)據(jù)共享,每臺(tái)服務(wù)器都能夠讀取session。
舉例來(lái)說(shuō), A網(wǎng)站和B網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)?,F(xiàn)在要求,用戶(hù)只要在其中一個(gè)網(wǎng)站登錄,再訪(fǎng)問(wèn)另一個(gè)網(wǎng)站就會(huì)自動(dòng)登錄,請(qǐng)問(wèn)怎么實(shí)現(xiàn)?這個(gè)問(wèn)題就是如何實(shí)現(xiàn)單點(diǎn)登錄的問(wèn)題
- 1.Nginx ip_hash 策略,服務(wù)端使用 Nginx 代理,每個(gè)請(qǐng)求按訪(fǎng)問(wèn) IP 的 hash 分配,這樣來(lái)自同一 IP 固定訪(fǎng)問(wèn)一個(gè)后臺(tái)服務(wù)器,避免了在服務(wù)器 A 創(chuàng)建 Session,第二次分發(fā)到服務(wù)器 B 的現(xiàn)象。
- 2.Session復(fù)制:任何一個(gè)服務(wù)器上的 Session 發(fā)生改變(增刪改),該節(jié)點(diǎn)會(huì)把這個(gè) Session 的所有內(nèi)容序列化,然后廣播給所有其它節(jié)點(diǎn)。

-
3.共享Session:將Session Id 集中存儲(chǔ)到一個(gè)地方,所有的機(jī)器都來(lái)訪(fǎng)問(wèn)這個(gè)地方的數(shù)據(jù)。這種方案的優(yōu)點(diǎn)是架構(gòu)清晰,缺點(diǎn)是工程量比較大。另外,持久層萬(wàn)一掛了,就會(huì)單點(diǎn)失敗;
另一種方案是服務(wù)器索性不保存session數(shù)據(jù)了,所有數(shù)據(jù)就保存在客戶(hù)端,每次請(qǐng)求都發(fā)回服務(wù)器。這種方案就是接下來(lái)要介紹的基于Token的驗(yàn)證;
Token
過(guò)程

- 1.用戶(hù)通過(guò)用戶(hù)名和密碼發(fā)送請(qǐng)求
- 2.程序驗(yàn)證
- 3.程序返回一個(gè)簽名的token給客戶(hù)端
- 4.客戶(hù)端儲(chǔ)存token, 并且每次用每次發(fā)送請(qǐng)求
- 5.服務(wù)端驗(yàn)證Token并返回?cái)?shù)據(jù)
這個(gè)方式的技術(shù)其實(shí)很早就已經(jīng)有很多實(shí)現(xiàn)了,而且還有現(xiàn)成的標(biāo)準(zhǔn)可用,這個(gè)標(biāo)準(zhǔn)就是JWT;
JWT(JSON Web Token)
數(shù)據(jù)結(jié)構(gòu)
實(shí)際的JWT大概就像下面這樣

JSON Web Tokens由dot(.)分隔的三個(gè)部分組成,它們是:
- Header(頭部)
- Payload(負(fù)載)
- Signature(簽名)
因此,JWT通常如下展示:
xxxxx.yyyyy.zzzz
Header(頭部)
Header 是一個(gè) JSON 對(duì)象
{
"alg": "HS256", // 表示簽名的算法,默認(rèn)是 HMAC SHA256(寫(xiě)成 HS256)
"typ": "JWT" // 表示Token的類(lèi)型,JWT 令牌統(tǒng)一寫(xiě)為JWT
}
Payload(負(fù)載)
Payload 部分也是一個(gè) JSON 對(duì)象,用來(lái)存放實(shí)際需要傳遞的數(shù)據(jù)
{
// 7個(gè)官方字段
"iss": "a.com", // issuer:簽發(fā)人
"exp": "1d", // expiration time: 過(guò)期時(shí)間
"sub": "test", // subject: 主題
"aud": "xxx", // audience: 受眾
"nbf": "xxx", // Not Before:生效時(shí)間
"iat": "xxx", // Issued At: 簽發(fā)時(shí)間
"jti": "1111", // JWT ID:編號(hào)
// 可以定義私有字段
"name": "John Doe",
"admin": true
}
JWT 默認(rèn)是不加密的,任何人都可以讀到,所以不要把秘密信息放在這個(gè)部分。
Signature(簽名)
Signature 是對(duì)前兩部分的簽名,防止數(shù)據(jù)被篡改。
首先,需要指定一個(gè)密鑰(secret)。這個(gè)密鑰只有服務(wù)器才知道,不能泄露給用戶(hù)。然后,使用Header里面指定的簽名算法(默認(rèn)是 HMAC SHA256),按照下面的公式產(chǎn)生簽名。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出簽名后,把 Header、Payload、Signature 三個(gè)部分拼成一個(gè)字符串,每個(gè)部分之間用"點(diǎn)"(.)分隔,就可以返回給用戶(hù)。
JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature
如何保證安全?
- 發(fā)送JWT要使用HTTPS;不使用HTTPS發(fā)送的時(shí)候,JWT里不要寫(xiě)入秘密數(shù)據(jù)
- JWT的payload中要設(shè)置expire時(shí)間
使用方式
客戶(hù)端收到服務(wù)器返回的 JWT,可以?xún)?chǔ)存在 Cookie 里面,也可以?xún)?chǔ)存在 localStorage。此后,客戶(hù)端每次與服務(wù)端通信,都要帶上這個(gè)JWT。你可以把它放在Cookie里面自動(dòng)發(fā)送,但是這樣不能跨域,所以更好的做法是放在HTTP請(qǐng)求的頭信息 Authorization 字段里面。
Authorization: Bearer <token>
另一種做法是, 跨域的時(shí)候, JWT就放在POST請(qǐng)求的數(shù)據(jù)體里。
JWT 的作用
JWT最開(kāi)始的初衷是為了實(shí)現(xiàn)授權(quán)和身份認(rèn)證作用的,可以實(shí)現(xiàn)無(wú)狀態(tài),分布式的Web應(yīng)用授權(quán)。大致實(shí)現(xiàn)的流程如下

- 1.客戶(hù)端需要攜帶用戶(hù)名/密碼等可證明身份的的內(nèi)容去授權(quán)服務(wù)器獲取JWT信息;
- 2.每次服務(wù)都攜帶該Token內(nèi)容與Web服務(wù)器進(jìn)行交互,由業(yè)務(wù)服務(wù)器來(lái)驗(yàn)證Token是否是授權(quán)發(fā)放的有效Token,來(lái)驗(yàn)證當(dāng)前業(yè)務(wù)是否請(qǐng)求合法。
這里需要注意:不是每次請(qǐng)求都要申請(qǐng)一次Token,這是需要注意,如果不是對(duì)于安全性要求的情況,不建議每次都申請(qǐng),因?yàn)闀?huì)增加業(yè)務(wù)耗時(shí);比如只在登陸時(shí)申請(qǐng),然后使用JWT的過(guò)期時(shí)間或其他手段來(lái)保證JWT的有效性;
Acesss Token,Refresh Token
JWT最大的優(yōu)勢(shì)是服務(wù)器不再需要存儲(chǔ)Session,使得服務(wù)器認(rèn)證鑒權(quán)業(yè)務(wù)可以方便擴(kuò)展。這也是JWT最大的缺點(diǎn)由于服務(wù)器不需要存儲(chǔ)Session狀態(tài),因此使用過(guò)程中無(wú)法廢棄某個(gè)Token,或者更改Token的權(quán)限。也就是說(shuō)一旦JWT簽發(fā)了,到期之前就會(huì)始終有效。我們可以基于上面提到的問(wèn)題做一些改進(jìn)。
前面講的Token,都是Acesss Token,也就是訪(fǎng)問(wèn)資源接口時(shí)所需要的Token,還有另外一種Token,Refresh Token。一般情況下,Refresh Token的有效期會(huì)比較長(zhǎng)。而Access Token的有效期比較短,當(dāng)Acesss Token由于過(guò)期而失效時(shí),使用Refresh Token就可以獲取到新的Token,如果Refresh Token也失效了,用戶(hù)就只能重新登錄了。Refresh Token及過(guò)期時(shí)間是存儲(chǔ)在服務(wù)器的數(shù)據(jù)庫(kù)中,只有在申請(qǐng)新的Acesss Token時(shí)才會(huì)驗(yàn)證,不會(huì)對(duì)業(yè)務(wù)接口響應(yīng)時(shí)間造成影響,也不需要向Session一樣一直保持在內(nèi)存中以應(yīng)對(duì)大量的請(qǐng)求。

一個(gè)簡(jiǎn)單的JWT使用示例
準(zhǔn)備
npm i --save koa koa-route koa-bodyparser @koa/cors jwt-simple
服務(wù)端代碼
const Koa = require("koa");
const app = new Koa();
const route = require('koa-route');
var bodyParser = require('koa-bodyparser');
const jwt = require('jwt-simple');
const cors = require('@koa/cors');
const secret = 'your_secret_string'; // 加密用的SECRET字符串,可隨意更改
app.use(bodyParser()); // 處理post請(qǐng)求的參數(shù)
const login = ctx => {
const req = ctx.request.body;
const userName = req.userName;
const expires = Date.now() + 1000 * 60; // 為了方便測(cè)試,設(shè)置超時(shí)時(shí)間為一分鐘后
const payload = {
iss: userName,
exp: expires
};
const Token = jwt.encode(payload, secret);
ctx.response.body = {
data: Token,
msg: '登陸成功'
};
}
const getUserName = ctx => {
const token = ctx.get('authorization').split(" ")[1];
const payload = jwt.decode(token, secret);
// 每次請(qǐng)求只判斷Token是否過(guò)期,不重新去更新Token過(guò)期時(shí)間(更新不更新Token的過(guò)期時(shí)間主要看實(shí)際的應(yīng)用場(chǎng)景)
if(Date.now() > payload.exp) {
ctx.response.body = {
errorMsg: 'Token已過(guò)期,請(qǐng)重新登錄'
};
} else {
ctx.response.body = {
data: {
username: payload.iss,
},
msg: '獲取用戶(hù)名成功',
errorMsg: ''
};
}
}
app.use(cors());
app.use(route.post('/login', login));
app.use(route.get('/getUsername', getUserName));
app.listen(3200, () => {
console.log('啟動(dòng)成功');
});
客戶(hù)端代碼
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>JWT-demo</title>
<style>
.login-wrap {
height: 100px;
width: 200px;
border: 1px solid #ccc;
padding: 20px;
margin-bottom: 20px;
}
</style>
</head>
<body>
<div class="login-wrap">
<input type="text" placeholder="用戶(hù)名" class="userName">
<br>
<input type="password" placeholder="密碼" class="password">
<br>
<br>
<button class="btn">登陸</button>
</div>
<button class="btn1">獲取用戶(hù)名</button>
<p class="username"></p>
</body>
<script>
var btn = document.querySelector('.btn');
btn.onclick = function () {
var userName = document.querySelector('.userName').value;
var password = document.querySelector('.password').value;
fetch('http://localhost:3200/login', {
method: 'POST',
body: `userName=${userName}&password=${password}`,
headers:{
'Content-Type': 'application/x-www-form-urlencoded'
},
mode: 'cors' // no-cors, cors, *same-origin
})
.then(function (response) {
return response.json();
})
.then(function (res) {
// 獲取到Token,將Token放在localStorage
document.cookie = `token=${res.data}`;
localStorage.setItem('token', res.data);
localStorage.setItem('token_exp', new Date().getTime());
alert(res.msg);
})
.catch(err => {
message.error(`本地測(cè)試錯(cuò)誤 ${err.message}`);
console.error('本地測(cè)試錯(cuò)誤', err);
});
}
var btn1 = document.querySelector('.btn1');
btn1.onclick = function () {
var username = document.querySelector('.username');
const token = localStorage.getItem('token');
fetch('http://localhost:3200/getUsername', {
headers:{
'Authorization': 'Bearer ' + token
},
mode: 'cors' // no-cors, cors, *same-origin
})
.then(function (response) {
return response.json();
})
.then(function (res) {
console.log('返回用戶(hù)信息結(jié)果', res);
if(res.errorMsg !== '') {
alert(res.errorMsg);
username.innerHTML = '';
} else {
username.innerHTML = `姓名:${res.data.username}`;
}
})
.catch(err => {
console.error(err);
});
}
</script>
</html>
運(yùn)行代碼

區(qū)別
Cookie和Session的區(qū)別
- 存儲(chǔ)位置不同:cookie數(shù)據(jù)存放在客戶(hù)的瀏覽器上,session數(shù)據(jù)放在服務(wù)器上
- 隱私策略不同:cookie不是很安全, 別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙,考慮到安全應(yīng)當(dāng)使用session
- session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪(fǎng)問(wèn)增多,就會(huì)比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面,應(yīng)當(dāng)使用cookie
- 存儲(chǔ)大小不同:?jiǎn)蝹€(gè)cookie保存的數(shù)據(jù)不能超過(guò)4k, 很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie
Token和Session的區(qū)別
Session是一種HTTP儲(chǔ)存機(jī)制, 為無(wú)狀態(tài)的HTTP提供持久機(jī)制; Token就是令牌, 比如你授權(quán)(登錄)一個(gè)程序時(shí),它就是個(gè)依據(jù),判斷你是否已經(jīng)授權(quán)該軟件;
Session和Token并不矛盾,作為身份認(rèn)證Token安全性比Session好,因?yàn)槊恳粋€(gè)請(qǐng)求都有簽名還能防止監(jiān)聽(tīng)以及重放攻擊,而Session就必須依賴(lài)鏈路層來(lái)保障通訊安全了。如上所說(shuō),如果你需要實(shí)現(xiàn)有狀態(tài)的回話(huà),仍然可以增加Session來(lái)在服務(wù)端保存一些狀態(tài)。
總結(jié)
無(wú)論是cookie session 還是token,在不同場(chǎng)景下都會(huì)有各自的應(yīng)用,在相同的場(chǎng)景下,有些問(wèn)題用cookie + session 或者token都可以去解決問(wèn)題,對(duì)于技術(shù)來(lái)說(shuō),存在即合理,沒(méi)有誰(shuí)好誰(shuí)不好,我們要做的是讀懂他們,了解他們的運(yùn)行原理,在我們遇到問(wèn)題時(shí),能有法可循。本地存儲(chǔ)的出現(xiàn),讓我們能夠基于此創(chuàng)建更豐富的web應(yīng)用,同時(shí)也意味著,我們的項(xiàng)目逐漸復(fù)雜起來(lái)。但萬(wàn)變不離其宗,我們掌握了事物的本質(zhì),多復(fù)雜的項(xiàng)目,我們都能一層一層的撥開(kāi)他們,用心去學(xué)。其實(shí),我們生而為人,也是這個(gè)道理,我說(shuō)的對(duì)嘛?大家,加油??!
參考鏈接:
詳解 Cookie,Session,Token
我是前端dog君,一名95后前端小兵。對(duì)前端的熱愛(ài),讓我們?cè)诖讼嗑?,希望這篇文章,能幫助到您,也同時(shí)希望能交到志同道合的小伙伴,共同發(fā)展,一起進(jìn)步。我的微信號(hào)dm120225,備注簡(jiǎn)書(shū),期待您的光臨。
