网上有很多文章描述为什么JWT是替换会话的破解解决方案，但我有一个模仿会话并基于JWT的实现，似乎足够安全：
- 一旦用户登录一组三个令牌，则返回：具有较短到期时间的jwt访问令牌，具有较长到期时间的jwt刷新令牌，常规csrf令牌。如果Web应用程序访问和刷新令牌存储在仅限http的安全cookie中，则csrf位于响应正文中，应由客户端处理：localStorage，in-memory - 由您决定。如果第三方客户端（移动，桌面等）访问和刷新令牌也在响应正文中。
- 网络和第三方客户端有不同的登录端点：一个用于网络只需要用户名（或电子邮件）和密码，第三方需要客户端ID和客户端密码 - 将此对视为app密钥：它们应该在客户端硬编码并存储在后端的数据库中。
- 每个刷新令牌只能有一个与之关联的有效访问令牌。访问令牌的有效负载包含令牌的uid - uuid4应该没问题。
- 当生成令牌时，应将两个条目添加到键值存储（redis，memcached等）中，如果商店支持，则具有适当的密钥到期超时
- [refresh-token-id] =＆gt; [csrf-token，access-token的uid，access-token的到期时间]
- [access-token-uid] =＆gt; [CSRF令牌]
- 不需要csrf令牌检查的API请求（GET / HEAD或来自第三方客户端的请求）应该只检查访问令牌本身并且不进行键值存储请求（或者如果你的话，可以执行'has-key'请求想拥有集中密码重置功能）。在csrf易受攻击的请求的情况下，单个键值存储请求完成 - ＆gt;检查请求的X-CSRF-Token标头是否包含正确的csrf标记
- 刷新令牌请求首先验证刷新令牌，然后发出键值存储请求并检查来自X-CSRF-Token头的csrf令牌是否有效以及访问令牌的到期时间是否合适 - ＆gt;这是对客户端实现的限制 - 只有在令牌过期时才应发送刷新请求，如果在访问令牌的到期时间之前发送刷新请求，则应向开发团队发送通知，因为在生产中它可能意味着刷新令牌劫持。
- 如果刷新令牌验证正常，则应更新键值存储键：应删除访问令牌的uid键，应创建新的访问令牌的uid键，更新csrf令牌并在响应中返回。
方法的优点：
- 只有当您需要解析当前用户时，访问验证逻辑才可能只生成单个数据库请求。一些有用的信息可能存储在访问令牌的有效载荷中 - ＆gt;您可以通过在令牌中拥有角色或其他特定于访问权限的数据并在其中验证它来完全不进行db / key-value存储调用来阻止api访问。在POST / PUT / PATCH / DELETE请求的情况下，仅发出单个键值存储请求 - 验证csrf令牌，仅在Web客户端的情况下，因为其他客户端不是易受攻击的。
- 阻止了用于刷新令牌的Cookie劫持 - ＆gt;由于每个刷新令牌只允许一个访问令牌，因此其所有者（有效用户或黑客）必须在当前访问令牌的到期超时之前进行刷新请求 - ＆gt;在这种情况下，开发团队可以收到有关特定刷新令牌的可疑活动的通知。
- 您同时支持网络和非网络客户
- 可以重置集中密码：您只需要为当前用户使所有刷新令牌无效，这意味着刷新令牌也应存储在数据库中，以便能够找到所有键值存储表示形式。刷新令牌。如果在密码重置后立即丢弃所有会话很重要，则应该对访问令牌进行额外检查 - ＆gt;检查其密钥是否仍在键值存储中。