我们决定从 Basic-Auth 切换到 JWT，因为 session-id 存储在内存中，有时会导致拍摄时内存消耗过多- 关闭我们的 Spring-Boot 服务器，该服务器为 Twitter 等 Android 移动应用提供服务。
但是对于我们的移动用例，我们有一些关于 JWT 的问题：
access-token 和refresh token 无效来注销用户？ （对于注销我们已经删除了移动应用端的令牌，但是如果令牌被某人窃取并且仍然有效怎么办？）【问题讨论】：
标签： spring spring-boot spring-security oauth-2.0 jwt
我的意思是看起来你应该只是使用会话。 JWT 并不是一个简单的替代品。它们具有特定的功能，并且由于某种原因，它们已被嵌入作为任何身份验证系统的某种自动访问。
根据您的描述（将基本身份验证提升为更安全和现代的身份验证系统），您应该使用会话。 很好的 Cookie 会话。
我会更详细地说明原因，但要总结一下：
A) 如果您只使用传统的基于 cookie 的会话，您可以控制会话，而不会奇怪地粘在“banlist”表和 JWT 的额外架构上.
B) 它们经过试验和测试，浏览器将保证它们的安全！会话 cookie 可以设置为“安全”和“仅限 http”。人们将 JWT 放置在许多奇怪的地方，包括浏览器的本地/会话存储，只是等待一个顽皮的 js 注入广告来吸收它们。 JWT，就像 SessionID 一样，应该 位于仅限 Http、安全且同站点的严格 Cookie 中。
因此，当浏览器非常满意时，您也可以只使用会话 ID 并在没有奇怪的前端状态管理的情况下继续生活，并在使用会话 Cookie 时为您安全地执行此操作。
C) 传统会话易于实施。更难理解它们如何/为什么与所有 SameSite/HttpOnly/CORS/Secure 部分一起工作......但是一旦理解，实现起来就容易了 99 倍，并且当 Spring 框架已经为您完成了 99% 时，需要更少的代码.
我的意思是确定编写自己的 JWTAuthTokenAuthFilter 并实现 JWTAuthenticationProvider 和 JWTCreationService 和 `JWTAutoRefreshFilter...以及您梦寐以求的任何其他东西...只需要一个会话。 Spring 用 20 行经过良好测试的代码来完成。
总结一下： 我的意思当然是正确实施的 JWT 是安全的……只是也许它们并不总是最适合工作的工具。
阅读：
当然，JWT 是有用的。他们是为了在客户端到达他们的 API 端点之前让第 3 方知道“是的，这是我认识的人”。或者说让您的一台服务器与您的另一台服务器通信......或让客户的服务器与您的服务器通信，甚至您的服务器与另一家公司通信：
【讨论】：
我会尽力回答你的问题
How long should an access token live?
您可以轻松配置到期时间，这取决于您的要求。 一般来说，尽量保持简短。
How long should the refresh token live?
以上适用于刷新令牌，条件是刷新令牌通常比访问令牌寿命更长，原因很明显。
How to logout a User by invalidating his access-token and refresh token?
这部分可能有点棘手。
您不能在创建令牌后手动使其过期。因此，您不能像使用会话那样在服务器端使用 JWT 注销。
可以实现一些选项，例如
添加一些链接以获得更深入的细节
【讨论】：