终于有人说清楚了，鉴权 5 兄弟：cookie

复制代码

HTTP 请求的 Cookie 头用于浏览器把符合当前「空间、时间、使用方式」配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。

Cookie: username=jimu; height=180; weight=80

复制代码

「前端对 cookie 的读写」 前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用document.cookie可以创建、修改 cookie，和 HTTP 一样，一次document.cookie能且只能操作一个 cookie。

document.cookie = ‘username=jimu; domain=jimu.com; path=/blog; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly’;

复制代码

调用document.cookie也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。

console.log(document.cookie);

// username=jimu; height=180; weight=80

复制代码

（就一个 cookie 属性，为什么读写行为不一样？get / set 了解下）「cookie 是维持 HTTP 请求状态的基石」了解了 cookie 后，我们知道 cookie 是最便捷的维持 HTTP 请求状态的方式，大多数前端鉴权问题都是靠 cookie 解决的。当然也可以选用别的存储方式（后面也会多多少少提到）。那有了存储工具，接下来怎么做呢？

应用方案：服务端 session

================

现在回想下，你刷卡的时候发生了什么？

其实你的卡上只存了一个 id（可能是你的学号），刷的时候物业系统去查你的信息、账户，再决定「这个门你能不能进」「这个鸡腿去哪个账户扣钱」。

这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：

• 浏览器登录发送账号密码，服务端查用户库，校验用户

• 服务端把用户登录状态存为 Session，生成一个 sessionId

• 通过登录接口返回，把 sessionId set 到 cookie 上

• 此后浏览器再请求业务接口，sessionId 随 cookie 带上

• 服务端查 sessionId 校验 session

• 成功后正常做业务处理，返回结果

「Session 的存储方式」 显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：

• Redis（推荐）：内存型数据库，redis中文官方网站。以 key-value 的形式存，正合 sessionId-sessionData 的场景；且访问快。

• 内存：直接放到变量里。一旦服务重启就没了

• 数据库：普通数据库。性能不高。

「Session 的过期和销毁」很简单，只要把存储的 session 数据销毁就可以。 「Session 的分布式问题」 通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。

• 一是从「存储」角度，把 session 集中存储。如果我们用独立的 Redis 或普通数据库，就可以把 session 都存到一个库里。

• 二是从「分布」角度，让相同 IP 的请求在负载均衡时都打到同一台机器上。以 nginx 为例，可以配置 ip_hash 来实现。

但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。「node.js 下的 session 处理」 前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session - npm，用法就不贴了。这是它种的 cookie：

express-session - npm 主要实现了：

• 封装了对cookie的读写操作，并提供配置项配置字段、加密方式、过期时间等。

• 封装了对session的存取操作，并提供配置项配置session存储方式（内存/redis）、存储规则等。

• 给req提供了session属性，控制属性的set/get并响应到cookie和session存取上，并给req.session提供了一些方法。

---

应用方案：token

==========

session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？

我又想到学校，在没有校园卡技术以前，我们都靠「学生证」。门卫小哥直接对照我和学生证上的脸，确认学生证有效期、年级等信息，就可以放行了。

回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。

token 的流程是这样的：

• 用户登录，服务端校验账号密码，获得用户信息

• 把用户信息、token 配置编码成 token，通过 cookie set 到浏览器

• 此后用户请求业务接口，通过 cookie 携带 token

• 接口校验 token 有效性，进行正常业务接口处理

「客户端 token 的存储方式」 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 「token 的过期」 那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。

token 的编码

---

编码的方式丰俭由人。「base64」 比如 node 端的 cookie-session - npm 库

不要纠结名字，其实是个 token 库，但保持了和 express-session - npm 高度一致的用法，把要存的数据挂在 session 上

默认配置下，当我给他一个 userid，他会存成这样：

这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb”} 的 base64 而已。「防篡改」

那问题来了，如果用户 cdd 拿{"userid":"abb”}转了个 base64，再手动修改了自己的 token 为 eyJ1c2VyaWQiOiJhIn0=，是不是就能直接访问到 abb 的数据了？

是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session - npm 库中，增加两项配置：

secret: ‘iAmSecret’,signed: true,

复制代码

这样会多种一个 .sig cookie，里面的值就是 {"userid":"abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (System.Security.Cryptography) | Microsoft Docs。

好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。「JWT」 但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introduction - jwt.io 横空出世了。

JSON Web Token (JWT) 是一个开放标准，定义了一种传递 JSON 信息的方式。这些信息通过数字签名确保可信。

它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyaWQiOiJhIiwiaWF0IjoxNTUxOTUxOTk4fQ.2jf3kl_uKWRkwjOP6uQRJFqMlwSABcgqqcJofFH5XCo

复制代码

这串东西是怎么生成的呢？看图：

类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 - JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt - npm koa-jwt - npm

refresh token

---

token，作为权限守护者，最重要的就是「安全」。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。

• access token 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活

• refresh token 用来获取 access token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 session 一样处理

有了 refresh token 后，几种情况的请求流程变成这样：

如果 refresh token 也过期了，就只能重新登录了。

session 和 token

---

session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是「种在 cookie 上、数据存 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。「客户端存 cookie / 存别地儿」 存 cookie 固然方便不操心，但问题也很明显：

• 在浏览器端，可以用 cookie（实际上 token 就常用 cookie），但出了浏览器端，没有 cookie 怎么办？

• cookie 是浏览器在域下自动携带的，这就容易引发 CSRF 攻击（前端安全系列（二）：如何防止CSRF攻击？- 美团技术团队）

存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。「服务端存数据 / 不存数据」

• 存数据：请求只需携带 id，可以大幅缩短认证字符串长度，减小请求体积

• 不存数据：不需要服务端整套的解决方案和分布式处理，降低硬件成本；避免查库带来的验证延迟

---

单点登录

====

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。

“虚假”的单点登录（主域名相同）

---

简单的，如果业务系统都在同一主域名下，比如wenku.baidu.com tieba.baidu.com，就好办了。可以直接把 cookie domain 设置为主域名 baidu.com，百度也就是这么干的。

“真实”的单点登录（主域名不同）

---

比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」