使用 Spring Security OAuth2 方法时我对两件事感到好奇。
是否可以不使用JSESSION或jwtToken而每次都检查access_token来进行身份验证？ 例如，第一次通过OAuth2认证颁发access_token和refresh_token并存储在JDBC（mysql）中。 在后续请求中，我想检索存储在mysql中的access_token并确定其有效性。
如果Spring Security OAuth2方法中的access_token已过期，使用refresh_token颁发新的access_token并在JDBC（mysql）中更新它的代码在哪里？
你的问题与Spring关系不大。它主要是关于 OAuth2（无论实现它的框架是什么），并且您显然需要更多有关 OAuth2 的背景知识。
您在 OAuth2 客户端的 OAuth2 授权服务器上对用户进行身份验证，以便该客户端可以获得令牌并将其请求授权给 OAuth2 资源服务器。到底是哪个演员有问题？
客户端（从中发起登录并存储令牌）和授权服务器（执行登录并颁发令牌）需要会话，对此您无能为力。资源服务器（使用令牌进行访问控制决策）可以在没有会话（无状态）的情况下进行配置，并且通常是因为它使得扩展和容错变得非常容易（任何实例都可以处理任何请求，并且您可以用任何其他实例替换任何实例）随时）。
OAuth2 客户端的默认 Spring Security 实现在会话中存储令牌，只是因为它在许多方面都是一个非常好的选择（比数据库更快，也更安全）。如果问题是跨客户端实例共享令牌，请考虑每个实例获取自己的令牌可能会更快，而且还有一个 spring-session 项目可以跨实例共享会话数据。
上验证令牌有两种选项：JWT 解码和内省。第二个涉及每个请求到授权服务器的往返，这似乎是您在第一个问题中寻找的内容，但这会严重影响性能。此外，如果 OAuth2 客户端正确实现，它不会带来任何安全性：“安全”客户端应该是保密的（在您信任的服务器上运行并使用秘密进行身份验证），并在用户注销时删除令牌（不应该有必要检查每个请求是否在授权服务器上关闭了会话，客户端上的会话应始终处于相同的状态）。即使授权服务器或客户端之一没有实现 Back-Channel Logout（在 Security 6.2.0 发布之前，Spring 客户端就是这种情况），客户端会话在授权服务器上的会话之后仍然有效已失效，您必须处于 SSO 配置（多个 OAuth2 客户端共享同一授权服务器），让用户使用另一个客户端注销，并且处于此注销和访问令牌过期之间，该持续时间应该很短（可能小于5 分钟）。 在 Spring security 中，带有令牌的 OAuth2 客户端的抽象是“授权客户端”。如果您想了解代币获取和刷新的内部原理，可以从
OAuth2AuthorizedClientManager开始探索源代码。