一文看懂Cookie、Session、Token的区别

cookie机制

cookie 是以 K-V 形式,存储在浏览器中一种数据。它可以在服务端设置,也可以在浏览器端用 js 代码设置。它拥有 maxAge、domain、path 等属性,借助这些属性,可以实现父子域名之间的数据传递。

虽然 cookie 是 K-V 形式存储的,但是在设置 cookie 的值的时候,是直接给定形如key1=value1; key2=value2的字符串。它在服务器/浏览器端均可以设置:

  • 浏览器端:通过 js 代码来设置,例如 document.cookie = "firstName=dongyuanxin; path=/
  • 服务器端:通过给 Http Response Headers 中的Set-Cookie字段赋值,来设置 cookie。客户端接收到Set-Cookie字段后,将其存储在浏览器中。

在服务端,以 koajs 为例,设置 key 为id,value 为xxoo521.com的 cookie。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
const Koa = require("koa");
const Router = require("koa-router");
const serve = require("koa-static");
const port = 3333;
const app = new Koa();
const router = new Router();
router.get("/api", async (ctx, next) => {
const cookie = ctx.cookies.get("id");
if (!cookie) {
// 设置 id = xxoo521.com
ctx.cookies.set("id", "xxoo521.com");
}
ctx.response.body = "原文地址:xxoo521.com";
});
app.use(serve("."))
.use(router.routes())
.listen(port, () => {
console.log("listen port:", port);
});

代码调试

在启动上面代码,并且请求/api接口后。在 Chrome Dev Tools 中,能看到服务器返回的 Headers

的信息,如下图:

006tNbRwly1gaw3m4rzgbj31lv0u0n5d.jpg

按照协议,浏览器应该成功保存了 cookies 的值。此时,找到Application => Storage => Cookies => 当前域名,即可验证 cookie

是否设置成功,如下图:

Untitled.png

整体流程

以用户购买商品为例,整体流程如下:

  • 监测到浏览器客户端没有标识用户的 cookie,跳转到登陆界面
  • 用户账号密码登陆,后端验证,成功后,在Set-cookie中设置标识用户的 cookie
  • 登陆成功,保存用户标识的 cookie
  • 购买商品,自动携带用户身份的 cookie,后端验证无误后,购买成功

总结

由此可见,单纯的使用 cookie,需要将用户的身份信息保存在客户端,并不安全。除此之外,cookie 还有大小限制,以及只能使用字符串类型作为 value 值。

Session机制

认识 Session

Session 机制准确来说,也是通过 K-V 数据格式来保存状态。其中:

  • Key:也称 SessionID,保存在客户端浏览器。
  • Value:也称“Session”,保存在服务端。

可以看到,客户端只需要存储 SessionID。具体映射的数据结构放在了服务端,因此跳出了仅仅浏览器 cookie 只可以存储 string 类型的限制。

而客户端存储 SessionID,还是需要借助 cookie 来实现。

整体流程

006tNbRwly1gaw5o64mrej30g30bzt9j.jpg

假设/login接口登陆成功后,服务器可以生成 sessionId 和 session。其中,session 中保存了过期时间,一些冗余信息等。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
router.get("/login", async (ctx, next) => {
const { user, pwd } = querystring.parse(ctx.request.search.slice(1));
// mock数据,模拟一下登陆过程
if (user === "test" && pwd === "123456") {
// 生成客户端存储的sessinId
const sessionId = crypto
.createHash("md5")
.update(user + pwd)
.digest("hex");
// 生成服务端存储的session
const session = {
expire: Date.now() + 1000 * 60 * 60 * 24, // 过期时间
info: {
// 保存的信息
name: user
}
};
sessions.set(sessionId, session);
ctx.cookies.set("sessionId", sessionId);
ctx.response.body = "登陆成功";
} else {
ctx.response.body = "登陆失败";
ctx.response.status = 401;
}
});

然后客户端在 cookies 中携带 sessionId,访问/userInfo接口,获得用户信息。服务端检查 sessionId 合法性,以及是否过期。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
router.get("/userInfo", async (ctx, next) => {
const sessionId = ctx.cookies.get("sessionId");
const session = sessions.get(sessionId);
// 如果sessionId不存在
if (!session) {
ctx.response.body = "无法识别身份";
ctx.response.status = 401;
return;
}
// session过期
if (session.expire <= Date.now()) {
ctx.response.body = "session过期,请重新登陆";
ctx.response.status = 401;
return;
}
ctx.response.body = session.info;
});

打开 chrome dev tools,我们可以看到,http 请求自动携带了 cookie 中的

sessionId。并且通过后端检验,拿到了用户信息。

006tNbRwly1gaw6736jk0j318q0u0jyh.jpg

session 传输数据少,数据结构灵活:相较于 cookie 来说,session 存储在服务端,客户端仅保留换取 session 的用户凭证。因此传输数据量小,速度快。

session 更安全:检验、生成、验证都是在服务端按照指定规则完成,而 cookie 可能被客户端通过 js 代码篡改。

session 的不足:服务器是有状态的。多台后端服务器无法共享 session。解决方法是,专门准备一台 session 服务器,关于 session 的所有操作都交给它来调用。而服务器之间的调用,可以走内网 ip,走 RPC 调用(不走 http)。

Token机制

为什么需要 Token?

这也是我刚接触 token 时候的疑惑,因为 session 对比 cookie 来说,解决了很多问题,所以感觉上 session 已经很完美了。

但对于 session 来说,服务器是有状态的。这个事情就很麻烦,尤其是在分布式部署服务的时候,需要共享服务器之间的状态。总不能让用户不停重复登陆吧?虽然专门准备一个服务器用来处理状态是可行的,但是能不能让服务器变成无状态的,还不能像单纯 cookie 那么蹩脚?

token 就解决了这个问题。它将状态保存在客户端,并且借助加密算法进行验证保证安全性。

整体流程

006tNbRwly1gax1s031v1j30zk0gkmyz.jpg

如上图所示,整体流程总结如下:

  • 用户尝试登陆
  • 登陆成功后,后端依靠加密算法,将凭证生成 token,返回给客户端
  • 客户端保存 token,每次发送请求时,携带 token
  • 后端再接收到带有 token 的请求时,验证 token 的有效性

在整个流程中,比较重要的是:生成 token、验证 token 的过程。这里设计一种简单的技术实现

  • 生成:token 的组成为:${user}.${HS256(user, secret)}。其中,secret 是加密需要的密钥,保存在服务端,不能泄漏。HS256 是加密算法,使用 RS256、HS512 也可以。
  • 验证:将请求中携带的 token 按照.分开,得到payloadsig。用服务器密钥对payload进行加密,将加密结果和sig比较,如果相同,那么通过验证。

值得一提的是,这里无需对sig进行解密。

代码实现

借助crypto实现 HS256 算法加密:

1
2
3
4
5
6
7
8
9
10
11
/**
* @param {string} content
* @param {string} key
* @return {string}
*/
function HS256(content, key = "jnajdnf9328u4") {
const hmac = crypto.createHmac("sha256", key);
hmac.update(content);
return hmac.digest("hex");
}

用户登陆成功后,将用户名作为payload,生成对应的sig,拼接为 token,返回给客户端:

1
2
3
4
5
6
7
8
9
10
11
12
router.get("/login", async (ctx, next) => {
const { user, pwd } = querystring.parse(ctx.request.search.slice(1));
// mock数据,模拟一下登陆过程
if (user === "test" && pwd === "123456") {
ctx.response.body = {
token: `${user}.${HS256(user)}`
};
} else {
ctx.response.body = "登陆失败";
ctx.response.status = 401;
}
});

客户端再请求需要用户身份的 api 的时候,应该携带 token,服务端对 token 合法性进行检验:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
router.get("/userInfo", async (ctx, next) => {
const { token } = querystring.parse(ctx.request.search.slice(1));
if (typeof token !== "string") {
ctx.response.body = "请携带token";
ctx.response.status = 401;
return;
}
const [payload, sig] = token.split(".");
if (!payload || !sig) {
ctx.response.body = "token格式不合法";
ctx.response.status = 401;
return;
}
if (HS256(payload) !== sig) {
ctx.response.body = "签名不合法";
ctx.response.status = 401;
return;
}
ctx.response.body = "用户信息是巴拉巴拉";
});

请求成功后,服务端返回数据,下图所示:

006tNbRwly1gax2flpn9rj31lo0u0gsa.jpg

总结:token 真香

token 的优点多多:

  • 服务器变成无状态了,实现分布式 web 应用授权
  • 可以进行跨域授权,不再局限父子域名
  • token 设计绝对了它本身可以携带更多不敏感数据,例如最常用的 JWT
  • 安全性更高,密钥保存在服务器。若密钥被窃取,可以统一重新下发密钥。

当然,token 增加了服务器压力(毕竟要加密)。但还是真香