前后端接口鉴权全解 Cookie/Session/Token 的区别 / 开普饭

今天

作者：ssshooter

不知不觉也写得比较长了，一次看不完建议收藏夹！本文主要解释与请求状态相关的术语（cookie、session、token）和几种常见登录的实现方式，希望大家看完本文后可以有比较清晰的理解，有感到迷惑的地方请在评论区提出。

Cookie

众所周知，http 是无状态协议，浏览器和服务器不可能凭协议的实现辨别请求的上下文。

于是 cookie 登场，既然协议本身不能分辨链接，那就在请求头部手动带着上下文信息吧。

举个例子，以前去旅游的时候，到了景区可能会需要存放行李，被大包小包压着，旅游也不开心啦。在存放行李后，服务员会给你一个牌子，上面写着你的行李放在哪个格子，离开时，你就能凭这个牌子和上面的数字成功取回行李。

cookie 做的正是这么一件事，旅客就像客户端，寄存处就像服务器，凭着写着数字的牌子，寄存处（服务器）就能分辨出不同旅客（客户端）。

你会不会想到，如果牌子被偷了怎么办，cookie 也会被偷吗？确实会，这就是一个很常被提到的网络安全问题——CSRF。

cookie 诞生初似乎是用于电商存放用户购物车一类的数据，但现在前端拥有两个 storage（local、session），两种数据库（websql、IndexedDB），根本不愁信息存放问题，所以现在基本上 100% 都是在连接上证明客户端的身份。例如登录之后，服务器给你一个标志，就存在 cookie 里，之后再连接时，都会自动带上 cookie，服务器便分清谁是谁。另外，cookie 还可以用于跟踪一个用户，这就产生了隐私问题，于是也就有了“禁用 cookie”这个选项（然而现在这个时代禁用 cookie 是挺麻烦的事情）。

设置方式

现实世界的例子明白了，在计算机中怎么才能设置 cookie 呢？一般来说，安全起见，cookie 都是依靠 set-cookie 头设置，且不允许 JavaScript 设置。

Set-Cookie: <cookie-name>=<cookie-value>Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>Set-Cookie: <cookie-name>=<cookie-value>; SecureSet-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=StrictSet-Cookie: <cookie-name>=<cookie-value>; SameSite=LaxSet-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// Multiple attributes are also possible, for example:Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

其中 <cookie-name>=<cookie-value> 这样的 kv 对，内容随你定，另外还有 HttpOnly、SameSite 等配置，一条 Set-Cookie 只配置一项 cookie。

img

Expires 设置 cookie 的过期时间（时间戳），这个时间是客户端时间。
Max-Age 设置 cookie 的保留时长（秒数），同时存在 Expires 和 Max-Age 的话，Max-Age 优先
Domain 设置生效的域名，默认就是当前域名，不包含子域名
Path 设置生效路径，/ 全匹配
Secure 设置 cookie 只在 https 下发送，防止中间人攻击
HttpOnly 设置禁止 JavaScript 访问 cookie，防止XSS
SameSite 设置跨域时不携带 cookie，防止CSRF

Secure 和 HttpOnly 是强烈建议开启的。SameSite 选项需要根据实际情况讨论，因为 SameSite 可能会导致即使你用 CORS 解决了跨越问题，依然会因为请求没自带 cookie 引起一系列问题，一开始还以为是 axios 配置问题，绕了一大圈，然而根本没关系。

其实因为 Chrome 在某一次更新后把没设置 SameSite 默认为 Lax，你不在服务器手动把 SameSite 设置为 None 就不会自动带 cookie 了。

发送方式

参考 MDN，cookie 的发送格式如下（其中 PHPSESSID 相关内容下面会提到）：

Cookie: <cookie-list>Cookie: name=valueCookie: name=value; name2=value2; name3=value3

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1

在发送 cookie 时，并不会把上面提到的 Expires 等配置传到服务器，因为服务器在设置后就不需要关心这些信息了，只要现代浏览器运作正常，收到的 cookie 就是没问题的。

Session

从 cookie 说到 session，是因为 session 才是真正的“信息”，如上面提到的，cookie 是容器，里面装着 PHPSESSID=298zf09hf012fh2;，这就是一个 session ID。

不知道 session 和 session id 会不会让你看得有点头晕？

当初 session 的存在就是要为客户端和服务器连接提供的信息，所以我将 session 理解为信息，而 session id 是获取信息的钥匙，通常是一串唯一的哈希码。

接下来分析两个 node.js express 的中间件，理解两种 session 的实现方式。

session 信息可以储存在客户端，如 cookie-session，也可以储存在服务器，如 express-session。使用 session ID 就是把 session 放在服务器里，用 cookie 里的 id 寻找服务器的信息。

客户端储存

对于 cookie-session 库，比较容易理解，其实就是把所有信息加密后塞到 cookie 里。其中涉及到 cookies 库。在设置 session 时其实就是调用 cookies.set，把信息写到 set-cookie 里，再返回浏览器。换言之，取值和赋值的本质都是操作 cookie。

浏览器在接收到 set-cookie 头后，会把信息写到 cookie 里。在下次发送请求时，信息又通过 cookie 原样带回来，所以服务器什么东西都不用存，只负责获取和处理 cookie 里的信息，这种实现方法不需要 session ID。

这是一段使用 cookie-session 中间件为请求添加 cookie 的代码：

const express = require('express')var cookieSession = require('cookie-session')const app = express()app.use(  cookieSession({    name: 'session',    keys: [      /* secret keys */      'key',    ],    // Cookie Options    maxAge: 24 * 60 * 60 * 1000, // 24 hours  }))app.get('/', function(req, res) {  req.session.test = 'hey'  res.json({    wow: 'crazy',  })})

app.listen(3001)

在通过 app.use(cookieSession()) 使用中间件之前，请求是不会设置 cookie 的，添加后再访问（并且在设置 req.session 后，若不添加 session 信息就没必要、也没内容写到 cookie 里），就能看到服务器响应头部新增了下面两行，分别写入 session 和 session.sig：

Set-Cookie: session=eyJ0ZXN0IjoiaGV5In0=; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponlySet-Cookie: session.sig=QBoXofGvnXbVoA8dDmfD-GMMM6E; path=/; expires=Tue, 23 Feb 2021 01:07:05 GMT; httponly

然后你就能在 DevTools 的 Application 标签看到 cookie 成功写入。session 的值 eyJ0ZXN0IjoiaGV5In0= 通过 base64 解码即可得到 {"test":"hey"}，这就是所谓的“将 session 信息放到客户端”，因为 base64 编码并不是加密，这就跟明文传输没啥区别，所以请不要在客户端 session 里放用户密码之类的机密信息。

即使现代浏览器和服务器做了一些约定，例如使用 https、跨域限制、还有上面提到 cookie 的 httponly 和 sameSite 配置等，保障了 cookie 安全。但是想想，传输安全保障了，如果有人偷看你电脑里的 cookie，密码又恰好存在 cookie，那就能无声无息地偷走密码。相反的，只放其他信息或是仅仅证明“已登录”标志的话，只要退出一次，这个 cookie 就失效了，算是降低了潜在危险。

说回第二个值 session.sig，它是一个 27 字节的 SHA1 签名，用以校验 session 是否被篡改，是 cookie 安全的又一层保障。

服务器储存

既然要储存在服务器，那么 express-session 就需要一个容器 store，它可以是内存、redis、mongoDB 等等等等，内存应该是最快的，但是重启程序就没了，redis 可以作为备选，用数据库存 session 的场景感觉不多。

express-session 的源码没 cookie-session 那么简明易懂，里面有一个有点绕的问题，req.session 到底是怎么插入的？

不关注实现可以跳过下面几行，有兴趣的话可以跟着思路看看 express-session 的源码：

我们可以从 .session = 这个关键词开始找，找到：

store.generate 否决这个，容易看出这个是初始化使用的
Store.prototype.createSession 这个是根据 req 和 sess 参数在 req 中设置 session 属性，没错，就是你了

于是全局搜索 createSession，锁定 index 里的 inflate（就是填充的意思）函数。

最后寻找 inflate 的调用点，是使用 sessionID 为参数的 store.get 的回调函数，一切说得通啦——

在监测到客户端送来的 cookie 之后，可以从 cookie 获取 sessionID，再使用 id 在 store 中获取 session 信息，挂到 req.session 上，经过这个中间件，你就能顺利地使用 req 中的 session。

那赋值怎么办呢？这就和上面储存在客户端不同了，上面要修改客户端 cookie 信息，但是对于储存在服务器的情况，你修改了 session 那就是“实实在在地修改”了嘛，不用其他花里胡哨的方法，内存中的信息就是修改了，下次获取内存里的对应信息也是修改后的信息。（仅限于内存的实现方式，使用数据库时仍需要额外的写入）

在请求没有 session id 的情况下，通过 store.generate 创建新的 session，在你写 session 的时候，cookie 可以不改变，只要根据原来的 cookie 访问内存里的 session 信息就可以了。

var express = require('express')var parseurl = require('parseurl')var session = require('express-session')

var app = express()

app.use(  session({    secret: 'keyboard cat',    resave: false,    saveUninitialized: true,  }))

app.use(function(req, res, next) {  if (!req.session.views) {    req.session.views = {}  }

  // get the url pathname  var pathname = parseurl(req).pathname

  // count the views  req.session.views[pathname] = (req.session.views[pathname] || 0) + 1

  next()})

app.get('/foo', function(req, res, next) {  res.json({    session: req.session,  })})

app.get('/bar', function(req, res, next) {  res.send('you viewed this page ' + req.session.views['/bar'] + ' times')})

app.listen(3001)

两种储存方式的对比

首先还是计算机世界最重要的哲学问题：时间和空间的抉择。

储存在客户端的情况，解放了服务器存放 session 的内存，但是每次都带上一堆 base64 处理的 session 信息，如果量大的话传输就会很缓慢。

储存在服务器相反，用服务器的内存拯救了带宽。

另外，在退出登录的实现和结果，也是有区别的。

储存在服务器的情况就很简单，如果 req.session.isLogin = true 是登录，那么 req.session.isLogin = false 就是退出。

但是状态存放在客户端要做到真正的“即时退出登录”就很困难了。你可以在 session 信息里加上过期日期，也可以直接依靠 cookie 的过期日期，过期之后，就当是退出了。

但是如果你不想等到 session 过期，现在就想退出登录！怎么办？认真想想你会发现，仅仅依靠客户端储存的 session 信息真的没有办法做到。

即使你通过 req.session = null 删掉客户端 cookie，那也只是删掉了，但是如果有人曾经把 cookie 复制出来了，那他手上的 cookie 直到 session 信息里的过期时间前，都是有效的。

说“即时退出登录”有点标题党的意味，其实我想表达的是，你没办法立即废除一个 session，这可能会造成一些隐患。

Token

session 说完了，那么出现频率超高的关键字 token 又是什么？

不妨谷歌搜一下 token 这个词，可以看到冒出来几个（年纪大的人）比较熟悉的图片：密码器。过去网上银行不是只要短信认证就能转账，还要经过一个密码器，上面显示着一个变动的密码，在转账时你需要输入密码器中的代码才能转账，这就是 token 现实世界中的例子。凭借一串码或是一个数字证明自己身份，这事情不就和上面提到的行李问题还是一样的吗……

**其实本质上 token 的功能就是和 session id 一模一样。**你把 session id 说成 session token 也没什么问题（Wikipedia 里就写了这个别名）。

其中的区别在于，session id 一般存在 cookie 里，自动带上；token 一般是要你主动放在请求中，例如设置请求头的 Authorization 为 bearer:<access_token>。

然而上面说的都是一般情况，根本没有明确规定！

剧透一下，下面要讲的 JWT（JSON Web Token）！他是一个 token！但是里面放着 session 信息！放在客户端，并且可以随你选择放在 cookie 或是手动添加在 Authorization！但是他就叫 token！

所以，个人觉得你不能通过存放的位置判断是 token 或是 session id，也不能通过内容判断是 token 或是 session 信息，session、session id 以及 token 都是很意识流的东西，只要你明白他是什么、怎么用就好了，怎么称呼不太重要。

另外在搜索资料时也看到有些文章说 session 和 token 的区别就是新旧技术的区别，好像有点道理。

在 session 的 Wikipedia 页面上 HTTP session token 这一栏，举例都是 JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、ASPSESSIONID (ASP) 等比较传统的技术，就像 SESSIONID 是他们的代名词一般；而在研究现在各种平台的 API 接口和 OAuth2.0 登录时，都是使用 access token 这样的字眼，这个区别着实有点意思。

理解 session 和 token 的联系之后，可以在哪里能看到“活的” token 呢？

打开 GitHub 进入设置，找到 Settings / Developer settings，可以看到 Personal access tokens 选项，生成新的 token 后，你就可以带着它通过 GitHub API，证明“你就是你”。

在 OAuth 系统中也使用了 Access token 这个关键词，写过微信登录的朋友应该都能感受到 token 是个什么啦。

Token 在权限证明上真的很重要，不可泄漏，谁拿到 token，谁就是“主人”。所以要做一个 Token 系统，刷新或删除 Token 是必须要的，这样在尽快弥补 token 泄漏的问题。

在理解了三个关键字和两种储存方式之后，下面我们正式开始说“用户登录”相关的知识和两种登录规范——JWT 和 OAuth2.0。

接着你可能会频繁见到 Authentication 和 Authorization 这两个单词，它们都是 Auth 开头，但可不是一个意思，简单来说前者是验证，后者是授权。在编写登录系统时，要先验证用户身份，设置登录状态，给用户发送 token 就是授权。

JWT

全称 JSON Web Token（RFC 7519），是的，JWT 就是一个 token。为了方便理解，提前告诉大家，JWT 用的是上面客户端储存的方式，所以这部分可能会经常用到上面提到的名称。

结构

虽说 JWT 就是客户端储存 session 信息的一种，但是 JWT 有着自己的结构：Header.Payload.Signature（分为三个部分，用 . 隔开）

Header

{  "alg": "HS256",  "typ": "JWT"}

typ 说明 token 类型是 JWT，alg 代表签名算法，HMAC、SHA256、RSA 等。然后将其 base64 编码。

Payload

{  "sub": "1234567890",  "name": "John Doe",  "admin": true}

Payload 是放置 session 信息的位置，最后也要将这些信息进行 base64 编码，结果就和上面客户端储存的 session 信息差不多。

不过 JWT 有一些约定好的属性，被称为 Registered claims，包括：

iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号

Signature

最后一部分是签名，和上面提到的 session.sig 一样是用于防止篡改，不过 JWT 把签名和内容组合到一起罢了。

JWT 签名的生成算法是这样的：

HMACSHA256(  base64UrlEncode(header) + "." +  base64UrlEncode(payload),  secret)

使用 Header 里 alg 的算法和自己设定的密钥 secret 编码 base64UrlEncode(header) + "." + base64UrlEncode(payload)

最后将三部分通过 . 组合在一起，你可以通过 jwt.io Debugger 形象地看到 JWT 的组成原理：

img

如何使用

在验证用户，顺利登录后，会给用户返回 JWT。因为 JWT 的信息没有加密，所以别往里面放密码，详细原因在客户端储存的 cookie 中提到。

用户访问需要授权的连接时，可以把 token 放在 cookie，也可以在请求头带上 Authorization: Bearer <token>。（手动放在请求头不受 CORS 限制，不怕 CSRF）

这样可以用于自家登录，也可以用于第三方登录。单点登录也是 JWT 的常用领域。

JWT 也因为信息储存在客户端造成无法让自己失效的问题，这算是 JWT 的一个缺点。

HTTP authentication

HTTP authentication 是一种标准化的校验方式，不会使用 cookie 和 session 相关技术。请求头带有 Authorization: Basic <credentials> 格式的授权字段。

其中 credentials 就是 Base64 编码的用户名 + : + 密码（或 token），以后看到 Basic authentication，意识到就是每次请求都带上用户名密码就好了。

Basic authentication 大概比较适合 serverless，毕竟他没有运行着的内存，无法记录 session，直接每次都带上验证就完事了。

OAuth 2.0

OAuth 2.0（RFC 6749）也是用 token 授权的一种协议，它的特点是你可以在有限范围内使用别家接口，也可以借此使用别家的登录系统登录自家应用，也就是第三方应用登录。（注意啦注意啦，OAuth 2.0 授权流程说不定面试会考哦！）

既然是第三方登录，那除了应用本身，必定存在第三方登录服务器。在 OAuth 2.0 中涉及三个角色：用户、应用提供方、登录平台，相互调用关系如下：

     +--------+                               +---------------+     |        |--(A)- Authorization Request ->|   Resource    |     |        |                               |     Owner     |     |        |<-(B)-- Authorization Grant ---|               |     |        |                               +---------------+     |        |     |        |                               +---------------+     |        |--(C)-- Authorization Grant -->| Authorization |     | Client |                               |     Server    |     |        |<-(D)----- Access Token -------|               |     |        |                               +---------------+     |        |     |        |                               +---------------+     |        |--(E)----- Access Token ------>|    Resource   |     |        |                               |     Server    |     |        |<-(F)--- Protected Resource ---|               |     +--------+                               +---------------+

很多大公司都提供 OAuth 2.0 第三方登录，这里就拿小聋哥的微信举例吧——

准备

一般来说，应用提供方需要先在登录平台申请好 AppID 和 AppSecret。（微信使用这个名称，其他平台也差不多，一个 ID 和一个 Secret）

获取 code

什么是授权临时票据（code）？答：第三方通过 code 进行获取 access_token 的时候需要用到，code 的超时时间为 10 分钟，一个 code 只能成功换取一次 access_token 即失效。code 的临时性和一次保障了微信授权登录的安全性。第三方可通过使用 https 和 state 参数，进一步加强自身授权登录的安全性。

在这一步中，用户先在登录平台进行身份校验。

https://open.weixin.qq.com/connect/qrconnect?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect

参数	是否必须	说明
appid	是	应用唯一标识
redirect_uri	是	请使用 urlEncode 对链接进行处理
response_type	是	填 code
scope	是	应用授权作用域，拥有多个作用域用逗号（,）分隔，网页应用目前仅填写 snsapi_login
state	否	用于保持请求和回调的状态，授权请求后原样带回给第三方。该参数可用于防止 csrf 攻击（跨站请求伪造攻击）

注意一下 scope 是 OAuth2.0 权限控制的特点，定义了这个 code 换取的 token 可以用于什么接口。

正确配置参数后，打开这个页面看到的是授权页面，在用户授权成功后，登录平台会带着 code 跳转到应用提供方指定的 redirect_uri：

redirect_uri?code=CODE&state=STATE

授权失败时，跳转到

redirect_uri?state=STATE

也就是失败时没 code。

获取 token

在跳转到重定向 URI 之后，应用提供方的后台需要使用微信给你的code获取 token，同时，你也可以用传回来的 state 进行来源校验。

要获取 token，传入正确参数访问这个接口：

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

参数	是否必须	说明
appid	是	应用唯一标识，在微信开放平台提交应用审核通过后获得
secret	是	应用密钥 AppSecret，在微信开放平台提交应用审核通过后获得
code	是	填写第一步获取的 code 参数
grant_type	是	填 authorization_code，是其中一种授权模式，微信现在只支持这一种

正确的返回：

{  "access_token": "ACCESS_TOKEN",  "expires_in": 7200,  "refresh_token": "REFRESH_TOKEN",  "openid": "OPENID",  "scope": "SCOPE",  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"}

得到 token 之后你就可以根据之前申请 code 填写的 scope 调用接口了。

使用 token 调用微信接口

授权作用域（scope）	接口	接口说明
snsapi_base	/sns/oauth2/access_token	通过 code 换取 `access_token`、refresh_token 和已授权 scope
snsapi_base	/sns/oauth2/refresh_token	刷新或续期 `access_token` 使用
snsapi_base	/sns/auth	检查 `access_token` 有效性
snsapi_userinfo	/sns/userinfo	获取用户个人信息

例如获取个人信息就是 GET https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN

注意啦，在微信 OAuth 2.0，access_token 使用 query 传输，而不是上面提到的 Authorization。

使用 Authorization 的例子，如 GitHub 的授权，前面的步骤基本一致，在获取 token 后，这样请求接口：

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com

说回微信的 userinfo 接口，返回的数据格式如下：

{  "openid": "OPENID",  "nickname": "NICKNAME",  "sex": 1,  "province":"PROVINCE",  "city":"CITY",  "country":"COUNTRY",  "headimgurl":"https://thirdwx.qlogo.cn/mmopen/g3MonUZtNHkdmzicIlibx6iaFqAc56vxLSUfpb6n5WKSYVY0ChQKkiaJSgQ1dZuTOgvLLrhJbERQQ4eMsv84eavHiaiceqxibJxCfHe/46",  "privilege":[ "PRIVILEGE1" "PRIVILEGE2" ],  "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"}

后续使用

在使用 token 获取用户个人信息后，你可以接着用 userinfo 接口返回的 openid，结合 session 技术实现在自己服务器登录。

// 登录req.session.id = openidif (req.session.id) {  //   已登录} else {  //   未登录}// 退出req.session.id = null// 清除 session

总结一下 OAuth2.0 的流程和重点：

为你的应用申请 ID 和 Secret
准备好重定向接口
正确传参获取 code <- 重要
code 传入你的重定向接口
在重定向接口中使用 code 获取 token <- 重要
传入 token 使用微信接口

OAuth2.0 着重于第三方登录和权限限制。而且 OAuth2.0 不止微信使用的这一种授权方式，其他方式可以看阮老师的OAuth 2.0 的四种方式。

其他方法

JWT 和 OAuth2.0 都是成体系的鉴权方法，不代表登录系统就一定要这么复杂。

简单登录系统其实就以上面两种 session 储存方式为基础就能做到。

使用服务器储存 session 为基础，可以用类似 req.session.isLogin = true 的方法标志该 session 的状态为已登录。
使用客户端储存 session 为基础，设置 session 的过期日期和登录人就基本能用了。

{  "exp": 1614088104313,  "usr": "admin"}

（就是和 JWT 原理基本一样，不过没有一套体系）

甚至你可以使用上面的知识自己写一个 express 的登录系统：
初始化一个 store，内存、redis、数据库都可以
在用户身份验证成功后，随机生成一串哈希码作为 token
用 set-cookie 写到客户端
再在服务器写入登录状态，以内存为例就是在 store 中添加哈希码作为属性
下次请求带着 cookie 的话检查 cookie 带来的 token 是否已经写入 store 中即可

let store = {}

// 登录成功后store[HASH] = truecookie.set('token', HASH)

// 需要鉴权的请求钟const hash = cookie.get('token')if (store[hash]) {  // 已登录} else {  // 未登录}

// 退出const hash = cookie.get('token')delete store[hash]

总结

以下列出本文重点：

cookie 是储存 session/session id/token 的容器
cookie 设置一般通过 set-cookie 请求头设置
session 信息可以存放在浏览器，也可以存放在服务器
session 存放在服务器时，以 session id 为钥匙获取信息
token/session/session id 三者的界限是模糊的
一般新技术使用 token，传统技术使用 session id
cookie/token/session/session id 都是用于鉴权的实用技术
JWT 是浏览器储存 session 的一种
JWT 常用于单点登录（SSO）
OAuth2.0 的 token 不是由应用端颁发，存在另外的授权服务器
OAuth2.0 常用于第三方应用登录

前后端接口鉴权全解 Cookie/Session/Token 的区别