清晰讲解Cookie、Session、Token、JWT之间的区别

古城微笑少年丶 2024-05-05 22:22 68阅读 0赞

#### 文章目录 ####

*  什么是认证(Authentication)
 *  什么是授权(Authorization)
 *  什么是凭证(Credentials)
 *  什么是Cookie
 *  什么是Session
 *   *  Session的痛点
 *  Cookie 和 Session 的区别
 *  什么是Token(令牌)
 *   *  Acesss Token
     *  Refresh Token
 *  Token 和 Session 的区别
 *  Token 与 Cookie
 *  什么是 JWT
 *   *  生成JWT
     *  JWT 的原理
     *  JWT的使用方式
     *   *  方式一
         *  方式二
         *  方式三
 *  Token 和 JWT 的异同
 *  常见的前后端鉴权方式
 *  常见的加密算法
 *  常见问题
 *   *  使用cookie时需要考虑的问题
     *  使用 session 时需要考虑的问题
     *  使用 token 时需要考虑的问题
     *  使用 JWT 时需要考虑的问题
     *  使用加密算法时需要考虑的问题
 *  网友提问
 *  参考

**以下内容为我结合他人知识进行的自我总结, 如有错误欢迎指出~**

## 什么是认证(Authentication) ##

通俗地讲就是验证当前用户的身份，证明“你是你自己”（比如：你每天上下班打卡，都需要通过指纹打卡，当你的指纹和系统里录入的指纹相匹配时，就打卡成功）

互联网中的认证：

*  用户名密码登录
 *  邮箱发送登录链接
 *  手机号接收验证码
 *  只要你能收到邮箱/验证码，就默认你是账号的主人

## 什么是授权(Authorization) ##

用户授予第三方应用访问该用户某些资源的权限

*  你在安装手机应用的时候，APP 会询问是否允许授予权限（访问相册、地理位置等权限）
 *  你在访问微信小程序时，当登录时，小程序会询问是否允许授予权限（获取昵称、头像、地区、性别等个人信息）

实现授权的方式有：cookie、session、token、OAuth

## 什么是凭证(Credentials) ##

实现**认证**和**授权**的前提是需要一种媒介(证书) 来标记访问者的身份

*  在战国时期，商鞅变法，发明了照身帖。照身帖由官府发放，是一块打磨光滑细密的竹板，上面刻有持有人的头像和籍贯信息。国人必须持有，如若没有就被认为是黑户，或者间谍之类的。
 *  在现实生活中，每个人都会有一张专属的居民身份证，是用于证明持有人身份的一种法定证件。通过身份证，我们可以办理手机卡/银行卡/个人贷款/交通出行等等，这就是认证的凭证。
 *  在互联网应用中，一般网站会有两种模式，游客模式和登录模式。游客模式下，可以正常浏览网站上面的文章，一旦想要点赞/收藏/分享文章，就需要登录或者注册账号。当用户登录成功后，服务器会给该用户使用的浏览器颁发一个令牌（**token**），这个令牌用来表明你的身份，每次浏览器发送请求时会带上这个令牌，就可以使用游客模式下无法使用的功能。

## 什么是Cookie ##

Cookie 是直接存储在浏览器中的一小串数据。它们是 HTTP 协议的一部分，由 RFC 6265 规范定义。

Cookie的工作机制如下  
![在这里插入图片描述][01d1692e1b574d2893e47fb0f42bcbdb.webp]  
以加入购物车为例，每次浏览器请求后 server 都会将本次商品 id 存储在 Cookie 中返回给客户端，客户端会将 Cookie 保存在本地，下一次再将上次保存在本地的 Cookie 传给 server 就行了，这样每个 Cookie 都保存着用户的商品 id，购买记录也就不会丢失了  
![在这里插入图片描述][f67905a6af89412d9e4d45756eca8da1.webp]  
仔细观察上图相信你不难发现**随着购物车内的商品越来越多，每次请求的 cookie 也越来越大，这对每个请求来说是一个很大的负担**，我只是想将一个商品加入购买车，为何要将历史的商品记录也一起返回给 server ？购物车信息其实已经记录在 server 了，浏览器这样的操作岂不是多此一举？**怎么改进呢** 接下来讲Session

*  HTTP 是**无状态的协议**（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要**通过 cookie 或者 session 去实现**。
 *  **cookie 存储在客户端**： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
 *  **cookie 是不可跨域的**： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的(靠的是 domain)。

[讲讲关于跨域的问题,什么是跨域?怎么办?][Link 1]

**cookie 重要的属性**

*  `name=value`: 键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型
    
     *  如果值为 Unicode 字符，需要为字符编码。
     *  如果值为二进制数据，则需要使用 BASE64 编码。
 *  `domain`: 指定 cookie 所属域名，默认是当前域名
 *  `path`: 指定 cookie 在哪个路径（路由）下生效，默认是`/` 。如果设置为`/abc` ，则只有`/abc` 下的路由可以访问到该 cookie，如：`/abc/read`。
 *  `maxAge`: cookie 失效的时间，单位秒。如果为整数，则该 cookie 在 maxAge 秒后失效。如果为负数，该 cookie 为临时 cookie ，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie 。如果为 0，表示删除该 cookie 。默认为 -1。- 比 expires 好用。
 *  `expires`: 过期时间，在设置的某个时间点后该 cookie 就会失效。一般浏览器的 cookie 都是默认储存的，当关闭浏览器结束这个会话的时候，这个 cookie 也就会被删除
 *  `secure`: 该 cookie 是否仅被使用安全协议传输。安全协议有 HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效。
 *  `httpOnly`: 如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本 读取到该 cookie 的信息，但还是能通过 Application 中手动修改 cookie，所以只是在一定程度上可以防止 XSS 攻击，不是绝对的安全

## 什么是Session ##

session 是另一种记录服务器和客户端会话状态的机制  
session 是基于 cookie 实现的，**session存储在服务器端**，**sessionId会被存储到客户端的cookie 中**  
![在这里插入图片描述][f11998bccb3f43e59ce0567600ff2d63.png]  
session 认证流程：

*  用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
 *  请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器(客户端)
 *  浏览器(客户端)接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
 *  当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，**SessionID 是连接 Cookie 和 Session 的一道桥梁**，大部分系统也是根据此原理来验证用户登录状态。

**根据上面Cookie中提到的购物车问题我们接着来说**

仔细考虑下，由于用户的购物车信息都会保存在 Server 中，所以在 **Cookie 里只要保存能识别用户身份的信息**，知道是谁发起了加入购物车操作即可，这样每次请求后只要在 Cookie 里带上用户的身份信息，请求体里也只要带上本次加入购物车的商品 id，**大大减少了 cookie 的体积大小**，我们把这种能识别哪个请求由哪个用户发起的**机制称为 Session**（**会话机制**），生成的能识别用户身份信息的字符串称为 sessionId，它的工作机制如下  
![在这里插入图片描述][162ccf8559654028930137af884a3b23.webp]

1.  首先用户登录，server 会为用户生成一个 session，为其分配唯一的 sessionId，这个 sessionId 是与某个用户绑定的，也就是说根据此 sessionid（假设为 abc） 可以查询到它到底是哪个用户，然后将此 sessionid 通过 cookie 传给浏览器
2.  之后浏览器的每次添加购物车请求中只要在 cookie 里带上 sessionId=abc 这一个键值对即可，server 根据 sessionId 找到它对应的用户后，把传过来的商品 id 保存到 server 中对应用户的购物车即可

可以看到通过这种方式再也不需要在 cookie 里传所有的购物车的商品 id 了，大大减轻了请求的负担！

另外通过上文不难观察出 **cookie 是存储在 client 的，而 session 保存在 server**，**sessionId 需要借助 cookie 的传递才有意义**。

### Session的痛点 ###

看起来通过 cookie + session 的方式是解决了问题， 但是我们忽略了一个问题，上述情况能正常工作是因为我们假设 server 是单机工作的，但实际在生产上，为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。  
![在这里插入图片描述][2d4b27129c0a4cbf9a905d3800600e27.png]  
如图示：**客户端请求后，由负载均衡器（如 Nginx）来决定到底打到哪台机器**

假设登录请求打到了 A 机器，A 机器生成了 session 并在 cookie 里添加 sessionId 返回给了浏览器，那么问题来了：下次添加购物车时如果请求打到了 B 或者 C，由于 session 是在 A 机器生成的，此时的 B,C 是找不到 session 的，那么就会发生无法添加购物车的错误，就得重新登录了，此时请问该怎么办。主要有以下三种方式

**方式一: session 复制**  
A 生成 session 后复制到 B, C，这样每台机器都有一份 session，无论添加购物车的请求打到哪台机器，由于 session 都能找到，故不会有问题  
![在这里插入图片描述][e4d361086d2f4ce1ba93190dc684e75c.png]  
这种方式虽然可行，但缺点也很明显：

*  同一样的一份 session 保存了多份，数据冗余
 *  如果节点少还好，但如果节点多的话，特别是像阿里，微信这种由于 DAU 上亿，可能需要部署成千上万台机器，这样节点增多复制造成的性能消耗也会很大。

**方式二: session 粘连**  
这种方式是让每个客户端请求只打到固定的一台机器上，比如浏览器登录请求打到 A 机器后，后续所有的添加购物车请求也都打到 A 机器上，Nginx 的 sticky 模块可以支持这种方式，支持按 ip 或 cookie 粘连等等，如按 ip 粘连方式如下

upstream tomcats {
    　　ip_hash;
    　　server 10.1.1.107:88;
    　　server 10.1.1.132:80;
    }

![在这里插入图片描述][75ee839575e0417e9609d056f37b83df.png]  
这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，**对应的机器挂了怎么办？**

**方式三: Session共享**  
这种方式也是目前各大公司普遍采用的方案，将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。  
![在这里插入图片描述][b3423215c512406e91ef1f489d7ececd.png]  
缺点其实也不难发现，就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能，另外为了保证 redis 的高可用，必须做**集群**，当然了对于大公司来说, redis 集群基本都会部署，所以这方案可以说是大公司的首选了。

接下来讲讲**Token**…

## Cookie 和 Session 的区别 ##

*  **安全性**： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
 *  **存取值的类型不同**：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
 *  **有效期不同：** Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
 *  **存储大小不同**： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

> **问**: cookie跟session怎么能做对比 不是一个类型的概念  
> **答**: 对于熟悉的人来说，肯定知道这两个不是一个维度的东西。但是对于不了解的人，需要放在一起对比，才能让他们知道这两个不是一个维度的  
> ![在这里插入图片描述][779518696ef54d68964f77a90a566a36.png]

## 什么是Token(令牌) ##

通过上文分析我们知道通过在服务端共享 session 的方式可以完成用户的身份定位，但是不难发现也有一个小小的瑕疵：搞个校验机制我还得搭个 redis 集群？大厂确实 redis 用得比较普遍，但对于小厂来说可能它的业务量还未达到用 redis 的程度，所以有没有其他不用 server 存储 session 的用户身份校验机制呢，这就是要介绍：token。

首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地，之后向 server 请求时在请求头带上此 token 即可。  
![在这里插入图片描述][c60fa0f3015f4b19ab26b38cc2a80d4d.png]  
相信大家看了上图会发现存在两个问题

1、 token 只存储在浏览器中，服务端却没有存储，这样的话我随便搞个 token 传给 server 也行？  
答：server 会有一套校验机制，校验这个 token 是否合法。

2、怎么不像 session 那样根据 sessionId 找到 userid 呢，这样的话怎么知道是哪个用户？  
答：token 本身携带 uid 信息

第一个问题，如何校验 token 呢？我们可以借鉴 HTTPS 的签名机制来校验。先来看 jwt token 的组成部分  
![在这里插入图片描述][4c0fabfa87564ba29e60e4b7aaa8d009.webp]  
可以看到 token 主要由三部分组成

1.  header：指定了签名算法
2.  payload：可以指定用户 id，过期时间等非敏感数据
3.  Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。

当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。而且你会发现 payload 中存有我们的 userId，所以拿到 token 后直接在 payload 中就可获取 userid，避免了像 session 那样要从 redis 去取的开销

### Acesss Token ###

*  访问资源接口（API）时所需要的资源凭证
 *  简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）
 *  特点：
    
     *  服务端无状态化、可扩展性好
     *  支持移动端设备
     *  安全
     *  支持跨程序调用

token 的身份验证流程：  
![在这里插入图片描述][264fa00cbc1341afa94bdbdb09086e14.png]

1.  客户端使用用户名跟密码请求登录
2.  服务端收到请求，去验证用户名与密码
3.  验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4.  客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5.  客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6.  服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

*  每一次请求都需要携带 token，需要**把 token 放到 HTTP 的 Header 里**
 *  基于 token 的用户认证是一种服务端**无状态**的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
 *  token 完全由应用管理，所以它可以避开同源策略

### Refresh Token ###

*  另外一种 token——refresh token
 *  refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。  
    ![在这里插入图片描述][d260ce0ac64e4946b644c4b5b4f7ec95.png]
 *  Access Token 的有效期比较短，当 Acesss Token 由于过期而失效时，使用 Refresh Token 就可以获取到新的 Token，如果 Refresh Token 也失效了，用户就只能重新登录了。
 *  Refresh Token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。

## Token 和 Session 的区别 ##

*  **Session** 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，**可以记录会话信息**。而 **Token** 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，**不会存储会话信息**。
 *  Session 和 Token 并不矛盾，**作为身份认证 Token 安全性比 Session 好**，因为每一个请求都有签名还能防止监听以及重放攻击，而Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
 *  所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：**如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了**。

session 和 token 本质上是没有区别的，都是对用户身份的认证机制，只是他们实现的校验机制不一样而已（一个保存在 server，通过在 redis 等中间件获取来校验，一个保存在 client，通过签名校验的方式来校验），多数场景上使用 session 会更合理，但如果在单点登录，一次性命令认证上使用 token 会更合适，最好在不同的业务场景中合理选型，才能达到事半功倍的效果。

## Token 与 Cookie ##

**Cookie 有哪些局限性？** 下面介绍两条  
1、 Cookie 跨站是不能共享的，这样的话如果你要实现多应用(多系统) 的**单点登录(SSO)**，使用 Cookie 来做需要的话就很困难了

PS: 所谓单点登录，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

但如果用 token 来实现 SSO 会非常简单，如下  
![在这里插入图片描述][98be4e68c9e2490082f1fd82476e9991.webp]  
只要在 header 中的 authorize 字段（或其他自定义）加上 token 即可完成所有跨域站点的认证。

2、 在移动端原生请求是没有 cookie 之说的，而 sessionid 依赖于 cookie，sessionid 就不能用 cookie 来传了，如果用 token 的话，由于它是随着 header 的 authoriize 传过来的，也就不存在此问题，换句话说token 天生支持移动平台，可扩展性好

综上所述，token 具有存储实现简单，扩展性好这些特点。

**token 有哪些缺点?** 下面介绍两条  
那有人就问了，既然 token 这么好，那为什么各个大公司几乎都采用共享 session 的方式呢，可能很多人是第一次听到 token，token 不香吗? token 有以下两点劣势：

1、 token 太长了: token 是 header, payload 编码后的样式，所以一般要比 sessionId 长很多，很有可能超出 cookie 的大小限制（cookie 一般有大小限制的，如 4kb），如果你在 token 中存储的信息越长，那么 token 本身也会越长，这样的话由于你每次请求都会带上 token，对请求来是个不小的负担

2、 不太安全: 网上很多文章说 token 更安全，其实不然，细心的你可能发现了，我们说 token 是存在浏览器的，再细问，存在浏览器的哪里？既然它太长放在 cookie 里可能导致 cookie 超限，那就只好放在 local storage 里，这样会造成安全隐患，因为 local storage 这类的本地存储是可以被 JS 直接读取的，另外由上文也提到，token 一旦生成无法让其失效，必须等到其过期才行，这样的话如果服务端检测到了一个安全威胁，也无法使相关的 token 失效。

所以 token 更适合一次性的命令认证，设置一个比较短的有效期

> **误解: Cookie 相比 token 更不安全，比如 CSRF 攻击**  
> 首先我们需要解释下 CSRF 攻击是怎么回事  
> 攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过（cookie 里带来 sessionId 等身份认证的信息），所以被访问的网站会认为是真正的用户操作而去运行。  
> 比如用户登录了某银行网站（假设为 `http://www.examplebank.com/`，并且转账地址为 `http://www.examplebank.com/withdraw?amount=1000&transferTo=PayeeName`），登录后 cookie 里会包含登录用户的 sessionid，攻击者可以在另一个网站上放置如下代码  
> `<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">`  
> 那么如果正常的用户误点了上面这张图片，由于相同域名的请求会自动带上 cookie，而 cookie 里带有正常登录用户的 sessionid，类似上面这样的转账操作在 server 就会成功，会造成极大的安全风险  
> ![在这里插入图片描述][676bf6d40b4b4939a2fdec22a2c22d23.png]  
> **CSRF 攻击的根本原因在于对于同样域名的每个请求来说，它的 cookie 都会被自动带上，这个是浏览器的机制决定的，所以很多人据此认定 cookie 不安全**。  
> 使用 token 确实避免了CSRF 的问题，但正如上文所述，由于 token 保存在 local storage，它会被 JS 读取，**从存储角度来看也不安全**（实际上防护 CSRF 攻击的正确方式是用 CSRF token）  
> 所以不管是 cookie 还是 token，从存储角度来看其实都不安全，都有暴露的风险，**我们所说的安全更多的是强调传输中的安全**，可以用 HTTPS 协议来传输， 这样的话请求头都能被加密，也就保证了传输中的安全。  
> 其实我们把 cookie 和 token 比较本身就不合理，一个是存储方式，一个是验证方式，正确的比较应该是 session vs token。

## 什么是 JWT ##

*  JSON Web Token（简称 JWT）是目前最流行的**跨域认证**解决方案。
 *  是一种**认证授权机制**。
 *  JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（RFC 7519）。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。
 *  可以使用 HMAC 算法或者是 RSA 的公/私秘钥对 JWT 进行签名。因为数字签名的存在，这些传递的信息是可信的。
 *  阮一峰老师的 JSON Web Token 入门教程 讲的非常通俗易懂，这里就不再班门弄斧了

### 生成JWT ###

[https://jwt.io/][https_jwt.io]

### JWT 的原理 ###

![在这里插入图片描述][e71973aaff7143ea8d595bae03ba41f5.png]  
JWT 认证流程：

*  用户输入用户名/密码登录，服务端认证成功后，会返回给客户端一个 JWT
 *  客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）
 *  当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样

Authorization: Bearer <token>

*  服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
 *  因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要
 *  因为 **JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）**
 *  因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制

### JWT的使用方式 ###

户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

#### 方式一 ####

当用户希望访问一个受保护的路由或者资源的时候，可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求头信息的 Authorization 字段里，使用 Bearer 模式添加 JWT。

GET /calendar/v1/events
    Host: api.example.com
    Authorization: Bearer <token>

*  用户的状态不会存储在服务端的内存中，这是一种 无状态的认证机制
 *  服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为。
 *  由于 JWT 是自包含的，因此减少了需要查询数据库的需要
 *  JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务，甚至是创建一个下载流服务。
 *  因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而**不需要担心跨域资源共享问题（CORS）**

#### 方式二 ####

跨域的时候，可以把 JWT 放在 POST 请求的数据体里。

#### 方式三 ####

通过 URL 传输

http://www.example.com/user?token=xxx

## Token 和 JWT 的异同 ##

相同：

*  都是访问资源的令牌
 *  都可以记录用户的信息
 *  都是使服务端无状态化
 *  都是只有验证成功后，客户端才能访问服务端上受保护的资源

区别：

*  Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
 *  JWT： 将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

## 常见的前后端鉴权方式 ##

*  Session-Cookie
 *  Token 验证（包括 JWT，SSO）
 *  OAuth2.0（开放授权）

## 常见的加密算法 ##

![在这里插入图片描述][483b3b30a1aa4dfe8ffe6367f013fc61.png]

*  哈希算法(Hash Algorithm)又称散列算法、散列函数、哈希函数，是一种从任何一种数据中创建小的数字“指纹”的方法。哈希算法将数据重新打乱混合，重新创建一个哈希值。
 *  哈希算法主要用来保障数据真实性(即完整性)，即发信人将原始消息和哈希值一起发送，收信人通过相同的哈希函数来校验原始数据是否真实。

**哈希算法**通常有以下几个特点：

*  正像快速：原始数据可以快速计算出哈希值
 *  逆向困难：通过哈希值基本不可能推导出原始数据
 *  输入敏感：原始数据只要有一点变动，得到的哈希值差别很大
 *  冲突避免：很难找到不同的原始数据得到相同的哈希值，宇宙中原子数大约在 10 的 60 次方到 80 次方之间，所以 2 的 256 次方有足够的空间容纳所有的可能，算法好的情况下冲突碰撞的概率很低：
    
     *  2 的 128 次方为 340282366920938463463374607431768211456，也就是 10 的 39 次方级别
     *  2 的 160 次方为 1.4615016373309029182036848327163e+48，也就是 10 的 48 次方级别
     *  2 的 256 次方为 1.1579208923731619542357098500869 × 10 的 77 次方，也就是 10 的 77 次方

**注意：**

1.  以上不能保证数据被恶意篡改，原始数据和哈希值都可能被恶意篡改，要保证不被篡改，可以使用RSA 公钥私钥方案，再配合哈希值。
2.  哈希算法主要用来防止计算机传输过程中的错误，早期计算机通过前 7 位数据第 8 位奇偶校验码来保障（12.5% 的浪费效率低），对于一段数据或文件，通过哈希算法生成 128bit 或者 256bit 的哈希值，如果校验有问题就要求重传。

## 常见问题 ##

### 使用cookie时需要考虑的问题 ###

*  因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
 *  不要存储敏感数据，比如用户密码，账户余额
 *  使用 httpOnly 在一定程度上提高安全性
 *  尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
 *  设置正确的 domain 和 path，减少数据传输
 *  **cookie 无法跨域**
 *  一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie
 *  移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以**移动端常用的是 token**

### 使用 session 时需要考虑的问题 ###

*  将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在**服务端定期的去清理过期的 session**
 *  当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
 *  当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
 *  sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie **怎么办**？ 一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现
 *  移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以**移动端常用的是 token**

### 使用 token 时需要考虑的问题 ###

*  如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。
 *  token 完全由应用管理，所以它可以避开同源策略
 *  token 可以**避免 CSRF 攻击**(因为不需要 cookie 了)
 *  移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以**移动端常用的是 token**

### 使用 JWT 时需要考虑的问题 ###

*  因为 JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
 *  JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
 *  JWT 不加密的情况下，不能将秘密数据写入 JWT。
 *  JWT **不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数**。
 *  JWT 最大的**优势**是服务器不再需要存储 Session，使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的**缺点**：由于服务器不需存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。
 *  JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
 *  JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小，由于每次操作都会生成新的 JWT，因此也没必要保存 JWT，真正实现无状态。
 *  为了减少盗用，JWT **不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输**。

### 使用加密算法时需要考虑的问题 ###

*  绝不要以明文存储密码
 *  永远使用 哈希算法 来处理密码，绝不要使用 Base64 或其他编码方式来存储密码，这和以明文存储密码是一样的，使用哈希，而不要使用编码。编码以及加密，都是双向的过程，而密码是保密的，应该只被它的所有者知道， 这个过程必须是单向的。哈希正是用于做这个的，从来没有解哈希这种说法， 但是编码就存在解码，加密就存在解密。
 *  绝不要使用弱哈希或已被破解的哈希算法，像 MD5 或 SHA1 ，只使用强密码哈希算法。
 *  绝不要以明文形式显示或发送密码，即使是对密码的所有者也应该这样。如果你需要 “忘记密码” 的功能，可以随机生成一个新的 一次性的（这点很重要）密码，然后把这个密码发送给用户。

## 网友提问 ##

> 问题一  
> 使用token时，服务端不用存放token，而是解析token数据，然后用解析出来的数据再去数据库查询用户信息。使用jwt时，解析jwt出来的数据以及包含了用户信息，不用再查询数据库。  
> **问**: 如果token里面加上用户信息，就不用查库了，那这样和jwt还有啥区别?  
> **答**: 这就是它们的区别啊, **token加上用户信息就是jwt了**啊

> 问题二  
> **问**: 跨域的话不是连ajax请求都发不出去，为什么在header头上加上了jwt就可以了呢?  
> **答**: 和jwt没关系，加上还是跨域，要后端配置允许跨域  
> **答**: 有很多地方写的确实不太清楚。他应该说的是跨域cookie带不上去。jwt只是在header里面加上一个头。  
> **答**: 跨域还是存在。不过jwt是设置在请求头中，即使跨域还是可以带到后端。而cookie在跨域时带不到后端。  
> **答**: 我是这么理解的，跨域现在通常的做法是nginx代理转发，token放cookie的话（因为cookie是属于浏览器的），nginx是没法转发的，token放request header，nginx转发的时候就直接带过去了。

> 问题三  
> **问**: 有个疑问想请教一下：是不是只有登录了，服务器才会就会产生一个sessionId，并保存这个session信息在服务器，如果是没有登录的一些请求，服务器是否还会产生一个sessionId，并保存当前session呢？我的理解是：没有登录，服务器应该不会产生session，肯定也不会保存当前session吧！毕竟服务器保存session需要额外的空间，而且这个session还是没有登录的session，不知道我的理解是否有误，还请赐教！  
> **答**: 不管用户有没有登录，都会创建 session 的，服务器需要记录会话信息（知道当前的访问者是谁），打个比方：如果同时有几百台浏览器访问服务器，如果不知道当前发过来的请求对应哪个浏览器，那么服务器就会发送错误的数据给浏览器  
> **问**: 您最后的这句话‘服务器会发送错误的数据给浏览器’我可以不可以这样理解，假设现在有三台浏览器同时访问一个服务器，他们一个在北京，一个在上海，一个在深圳，都是没有登录的，如果服务器没有保存他们三个的session，可能服务器返回的时候，将本来要返回给上海那台浏览器的数据，错误的返回给深圳的那台浏览器了，这样就会导致返回数据无法无法和请求的浏览器一一对应，是这个意思吗？？  
> **答**:是的  
> **答**: 如果你的服务器，就是存一些静态的网页，很典型的就是一些简单的个人博客，不会创建session的。而且不会发错，你一个http请求都包含了要请求的内容，返回的内容肯定根据请求来。几百个浏览器同时请求一个博客的页面，他们发送的http请求中就包含了各自的信息。http是建立在tcp的基础上的。。。  
> **接着问**: 你好，我对这个问题的回答存疑。既然用户没有登录，为什么服务器需要记录session以知道是谁在访问，没有登录的情况下，任何浏览器发送同样一个请求，返回的数据难道不是一样的吗？  
> **答**: 拿京东举例子，他们家网站可以在没登录前加入购物车，并且会一直保存这个会话信息。即没登录就创建了session. 和你有没有登陆没关系，session保存的是会话的信息

> 问题四  
> **问**: “用解析 token 的计算时间换取 session 的存储空间”，对于这句话，我想问一下，那每次客户端携带token请求服务端，服务端是如何进行判断该请求是同一个人的？进行token的判断，服务端的判断数据是从哪里来的？  
> **答**: 就是通过解密客户端发过来的token拿到payload，里面一般都会有用户唯一标识，用户名还有颁发时间，然后通过唯一标识去数据库中查询对应的数据  
> **问**: token 可以窃取吗，如果我窃取了别人的 token 我能不能伪装他欺骗服务器？如果可以伪装别人的身份，那是不是说明 token 在安全性上和 session 区别不大，token 的意义更在于减轻了服务器内存的压力和跨域请求？  
> **答**: 如果为了安全性考虑，token就会增加IP字段，后端检测时如果token的ip与当前请求的IP不一致就可以判定是否网络环境变更，如果要多台设备登陆就需要增设设备白名单。根据业务来选择途经，如果重要的业务可能还需要加入手机号码，指纹或者面容认证。然后选择token因为服务器不用维护状态了也确实减少服务器查询次数和改写次数，减轻了服务器的负担。

> 问题五  
> **问**: jwt那个token如果保存在localstore里 不是可以看到吗 那别人拿到直接使用postman这种工具不就可以直接访问吗 其实我也不太懂具体怎么防止别人窃取数据的  
> **答**: 所以设置 jwt 签发的时间不能太长，如果需要废弃 token ，还得服务端做另外的逻辑

> 问题六  
> **问**: 按照一开始的解释，cookie和session这两都不是一类东西啊，为啥还有区别比较，越看越迷糊了  
> **答**: Session是一种机制，cookies是一段信息，比较的话，应该是**存储在服务器端的sessionID所对应的那个对象 ”session对象“和cookies**比较, 大多博客这点其实没讲特别清楚  
> **答**: 你可以看做是两者都能存储信息，cookie存储在浏览器，session存储在服务器，数据大就放到session，而与此同时session是基于cookie实现的

## 参考 ##

侵删  
[傻傻分不清之 Cookie、Session、Token、JWT][Cookie_Session_Token_JWT]  
[还分不清 Cookie、Session、Token、JWT？][Cookie_Session_Token_JWT 1]  
[一文讲透Token与Cookie、Session的区别][Token_Cookie_Session]

[01d1692e1b574d2893e47fb0f42bcbdb.webp]: https://img-blog.csdnimg.cn/direct/01d1692e1b574d2893e47fb0f42bcbdb.webp
[f67905a6af89412d9e4d45756eca8da1.webp]: https://img-blog.csdnimg.cn/direct/f67905a6af89412d9e4d45756eca8da1.webp
[Link 1]: https://blog.csdn.net/mfysss/article/details/135522047?spm=1001.2014.3001.5502
[f11998bccb3f43e59ce0567600ff2d63.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/19ede5ccb5e144688d404d025476eb75.png
[162ccf8559654028930137af884a3b23.webp]: https://img-blog.csdnimg.cn/direct/162ccf8559654028930137af884a3b23.webp
[2d4b27129c0a4cbf9a905d3800600e27.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/23e853a8a9934d9db8bb3daf51418c4b.png
[e4d361086d2f4ce1ba93190dc684e75c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/3b63b71c7f6e4e6a8055efeda0534c33.png
[75ee839575e0417e9609d056f37b83df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/7ecb6cdc8dea4768b7ed12f2b8e6eeea.png
[b3423215c512406e91ef1f489d7ececd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/cbf386189b6b4012ac4c94057fc0fbf8.png
[779518696ef54d68964f77a90a566a36.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/b245c329ac414f78bd36c71a3157e1c2.png
[c60fa0f3015f4b19ab26b38cc2a80d4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/ae000c32e7c541f7a77301bf08d2e564.png
[4c0fabfa87564ba29e60e4b7aaa8d009.webp]: https://img-blog.csdnimg.cn/direct/4c0fabfa87564ba29e60e4b7aaa8d009.webp
[264fa00cbc1341afa94bdbdb09086e14.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/9d63f3e831864fdba4656cf2c91ee7a0.png
[d260ce0ac64e4946b644c4b5b4f7ec95.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/f4818cfab608423c9083911a8a96aa88.png
[98be4e68c9e2490082f1fd82476e9991.webp]: https://img-blog.csdnimg.cn/direct/98be4e68c9e2490082f1fd82476e9991.webp
[676bf6d40b4b4939a2fdec22a2c22d23.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/e84703e4ef3d4c31ad312cd2afa5ae75.png
[https_jwt.io]: https://jwt.io/
[e71973aaff7143ea8d595bae03ba41f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/e8a8bd4fbb1e40f087b9b6b62c1fd8af.png
[483b3b30a1aa4dfe8ffe6367f013fc61.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/370fb0b418c54daeab560b83431b26a0.png
[Cookie_Session_Token_JWT]: https://juejin.cn/post/6844904034181070861
[Cookie_Session_Token_JWT 1]: https://zhuanlan.zhihu.com/p/164696755
[Token_Cookie_Session]: https://zhuanlan.zhihu.com/p/625995458