以下 是 撤消 JWT 访问 标记 的 步骤 ：
1.登录 时 ， 发送 2 个 令牌 （ 访问 令牌 、 刷新 令牌 ） 以 响应 客户 端 。
1.访问 令牌 将 具有 较 短 的 过期 时间 ， 而 刷新 将 具有 较 长 的 过期 时间 。
1.客户 端 （ 前端 ） 将 在 其 本地 存储 中 存储 刷新 令牌 ， 并 在 cookie 中 存储 访问 令牌 。
1.客户 端 将 使用 一 个 访问 令牌 来 调用 API ， 但 当 它 过期 时 ， 您 可以 调用 auth 服务 器 API 来 获取 新 的 令牌 （ 刷新 令牌 会 自动 添加 到 http 请求 中 ， 因为 它 存储 在 cookie 中 ） 。
1.您 的 身份 验证 服务 器 将 公开 一 个 API ， 该 API 将 接受 刷新 令牌 并 检查 其 有效 性 ， 然后 返回 一 个 新 的 访问 令牌 。
1.刷新 令牌 过期 后 ， 用户 将 被 注销 。
请 让 我 知道 ， 如果 你 需要 更多 的 细节 ， 我 可以 分享 代码 （ Java + Spring 启动 ） 以及 。
对于 您 的 问题 ：
Q1 ： 这 是 另 一 个 JWT ， 提出 的 索赔 较少 ， 有效 期 较 长 。
Q2 ： 它 不会 在 数据 库 中 。 后端 不会 存储 在 任何 地方 。 他们 只 会 用 私钥/公钥 解密 令牌 ， 并 用 它 的 到期 时间 来 验证 它 。
Q3 ： 是 ， 正确

假设 这 与 OAuth 2.0 有关 ， 因为 它 与 JWT 和 刷新 令牌 有关 ... ... ：
1.就 像 访问 令牌 一样 ， 原则 上 ， 刷新 令牌 可以 是 任何 东西 ， 包括 您 描述 的 所有 选项 ;当 授权 服务 器 希望 成为 无 状态 的 或者 希望 对 提供 它 的 客户 机 强制 某种 " 拥有 证明 " 语义 时 ， 可以 使用 JWT ;请 注意 ， 刷新 令牌 与 访问 令牌 的 不同 之 处 在于 ， 它 不 提供 给 资源 服务 器 ， 而 只 提供 给 首先 发布 它 的 授权 服务 器 ， 因此 JWTs-as - access-token 的 自 包含 验证 优化 不 适用 于 刷新 令牌
1.这 取决 于 数据 库 的 安全/访问 ;如果 其他 方/服务 器/应用 程序/用户 可以 访问 数据 库 ， 则 可以 （ 但 您 的 里程 可能 因 存储 加密 密钥 的 位置 和 方式 而 异 ... ）
1.授权 服务 器 可以 同时 发出 访问 令牌 和 刷新 令牌 ， 这 取决 于 客户 端 用来 获得 它们 的 授权 ;该 规范 包含 每个 标准 化 授权 的 详细 信息 和 选项

基于此implementation with Node.js of JWT with refresh token：
1.在这种情况下，它们使用uid，而不是JWT。当它们刷新标记时，它们会发送刷新标记和用户。如果将其实现为JWT，则不需要发送用户，因为它将位于JWT内部。
1.他们在单独的文档（表）中实现了这一点。这对我来说很有意义，因为用户可以在不同的客户端应用程序中登录，并且可以按应用程序获得刷新令牌。如果用户丢失了安装了一个应用程序的设备，则该设备的刷新令牌可以失效，而不会影响其他登录的设备。
1.在这个实现中，它用访问令牌和刷新令牌来响应登录方法。

OAuth 2.0 specification document中描述了刷新令牌流。

+--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
  
  
  (A)  The client requests an access token by authenticating with the
       authorization server and presenting an authorization grant.
  
  (B)  The authorization server authenticates the client and validates
       the authorization grant, and if valid, issues an access token
       and a refresh token.
  
  (C)  The client makes a protected resource request to the resource
       server by presenting the access token.
  
  (D)  The resource server validates the access token, and if valid,
       serves the request.
  
  (E)  Steps (C) and (D) repeat until the access token expires.  If the
       client knows the access token expired, it skips to step (G);
       otherwise, it makes another protected resource request.
  
  (F)  Since the access token is invalid, the resource server returns
       an invalid token error.
  
  (G)  The client requests a new access token by authenticating with
       the authorization server and presenting the refresh token.  The
       client authentication requirements are based on the client type
       and on the authorization server policies.
  
  (H)  The authorization server authenticates the client and validates
       the refresh token, and if valid, issues a new access token (and,
       optionally, a new refresh token).

关于您的问题：
1.它是另一个JWT
1.刷新令牌必须存储在服务器端
1.是的

JWT 有 两 个 问题 ：
1.糟糕 的 标准 化
1.很 难 撤销 （ 用于 身份 验证 时 ）
第 一 个 问题 可以 通过 使用 您 自己 的 JWT 实现 来 解决 ：在 JSON 中 放入 您 想要 任何 内容 ， 使用 AES 加密 它 - 瞧 - 使用 它 进行 身份 验证 （ 如果 需要 ， 还 可以 进行 授权 ：将 角色 放入 JSON ） 。
超 简约 JWT {"id" : "<id>"}
第 二 个 问题 需要 澄清 。 对于 存储 在 服务 器 端 的 常规 会话 ， 不 存在 撤销 问题 ：服务 器 可以 在 任何 时候 使 会话 无效 。 2 但是 常规 的 会话 在 可 伸缩 性 和 性能 方面 存在 问题 ， 因此 JWT 也 是 如此 。
撤销 问题 的 常见 解决 方案 是 使用 * refresh-token * 。
以下 是 具体 操作 方法 ：
1.* refresh 标记 * 可以 是 与 * access-token * 完全 相同 的 JWT ：自 定义 JSON 加密 和 base64 编码 。 结果 字符 串 可以 重复 。 如果 * access-token * 包含 大量 数据 （ 例如 角色 ） ， 刷新 令牌 可能 会 有所 不同 ， 因为 它 只 需要 用户 ID 。 * access * 和 * refresh token * 内部 都 没有 任何 到期 硬 编码 。
1.它们 都 存储 在 * https _ only * Cookie 中 ， 但 * access-token * Cookie 的 过期 时间 为 * * 2 分钟 * * ， * refresh-token * Cookie 的 过期 时间 为 * * 30 分钟 * * 。
1.* Refresh-token * 存储 在 DB （ 用户 表 ） 中 ， 可 通过 从 DB 中 删除 轻松 撤销/无效 。
1.服务 器 在 请求 中 查找 * access-token * ：如果 存在 且 有效 （ 可 解密 ） - OK 处理 请求 ;
1.如果 * access-token * 不 存在 （ cookie 已 过期 ） ， 服务 器 将 查找 * refresh-token * ：如果 存在 - 通过 将 其 与 存储 在 DB 中 的 访问 令牌 进行 比较 来 进行 验证 ， 并 生成 新 的 * 访问 令牌 * （ 基于 来自 刷新 令牌 和 DB 的 信息 ） 并 处理 请求 。
1.如果 * refresh-token * 不 存在 ， 则 服务 器 将 查找 以下 内容 之 一 ：用户 名 - 密码 对 、 第 三方 身份 提供 商 令牌 （ Google 、 Facebook 等 ） 、 第 三方 身份 管理 系统 令牌 （ Cognito 、 Okta 、 JumpCloud ） 。 如果 找到 任何 令牌 ：处理 请求 并 生成 新 的 * 访问 和 刷新 令牌 * 。
1.如果 找 不到 任何 内容 ， 则 服务 器 会 发送 一 个 身份 验证 错误 ， 并 强制 客户 端 让 用户 重新 登录 。