我有两个客户端，一个是由常规最终用户通过我们的网页或本机应用程序登录的公共客户端，另一个是客户管理系统的机密客户端。两者都发出两个JWT，一个访问令牌和一个刷新令牌。
公共客户端不允许发布管理员权限。访问令牌是短暂的，刷新令牌具有无限的寿命。
允许机密客户端发布管理范围。访问令牌是短暂的，刷新令牌生活24小时。
使用Spring Security及其oAuth2实现，一旦刷新令牌过期，是否有可能降级管理员用户？也就是说，一旦用户登录24小时，用户就不会完全注销，但在下次登录时，他会获得两个新的JWT，一个用于常规用户访问的访问令牌和一个用于该访问级别的匹配刷新令牌。我想我正在寻找Spring Security框架中的某种钩子，它允许我以自定义的方式处理令牌过期。
答案 0 :(得分：1)
你的问题上的一句话让我感到困惑，但我想详细说明其他方面，所以这不符合评论。
...用户未完全注销，但在下一次登录时他获得了两个新的JWT，一个用于常规用户访问的访问令牌和一个用于该用户的匹配刷新令牌访问级别。
您在下次登录时对的确切含义是什么？我的困惑在于，如果目标不是注销用户，那么赢了是下一次登录。我想这可能意味着几乎到刷新令牌到期结束时你会想要做你的降级请求并使用仍然有效的刷新令牌来获得一对具有较少权限的新令牌。
根据OAuth规范，您可以执行刷新令牌请求，并向服务器询问范围小于您当前范围的访问令牌。但是，它还规定如果返回新的刷新令牌，则该令牌需要与请求中包含的刷新令牌具有完全相同的范围。
就个人而言，对于这种情况，我会考虑而不是降级令牌，只需确保为了执行任何管理员相关操作，用户必须是管理员并且在过去24小时内实际提供了他的凭据。您可以通过跟踪给定用户实际执行登录的日期和时间（通过提供其凭据）然后根据该值授权管理员操作来实现此目的。这样，您可以为机密客户端增加刷新令牌的生命周期，并且只有当管理员想要执行特权任务并且他们当前的令牌不够新鲜时才强制管理员再次登录。
最后，仍然关注refresh tokens的主题（重点关注安全注意事项部分）...当您说公共客户的网络应用时，我假设它＆ ＃39;基于浏览器的Javascript应用程序。如果这是正确的，通常不建议对这些应用程序使用刷新令牌，因为刷新令牌通常是长期存在的（在您的情况下它们似乎永不过期）并且浏览器无法确保它们的安全存储。这增加了它们泄漏的可能性，这会使攻击者在令牌的生命周期内访问应用程序。您可能还有其他限制条件使得这种安全性考虑不适用，但我仍然希望引起您的注意。