Question

我将为几个独立服务实现JWT身份验证。将有auth.example.com和service1.example.com，service2.example.com等。

我的假设：

JWT可以保存在“.example.com”
JWT过期时间应该很小（比如15分钟），因为没有可靠的方法来注销用户使用JWT令牌（撤销令牌）。
刷新令牌应该用于重新颁发JWT令牌
出于安全原因，只有auth.example.com才能访问刷新令牌Cookie，因为https://tools.ietf.org/html/rfc6749#section-1.5说 “与访问令牌不同，刷新令牌仅用于授权服务器，不会发送到资源服务器。”

接下来，如果我有一个服务 - 多页面应用程序（即不是SPA），其中一些URL被称为“传统”方式，而不是通过Ajax和呈现HTML 基于某些服务器端逻辑，当然包括检查用户授权。

然后，比如说，会有一个动作service1.example.com/user/showpage

if (user.logged_in) {
  render_some_html(get_some_data(user.login))
}
else {
  render_anonimous_uses_page()
}

问题：

如果网站用户关闭了所有网站标签，那么大约一小时后，直接转到页面/用户/展示页面（或者也许是他暂停笔记本电脑并在一小时内将其唤醒并转到该页面。）

如果到那时JWT令牌将过期怎么办？然后通过刷新令牌刷新它我们需要对auth.example.com进行Ajax调用（因为刷新令牌只存储在auth.example.com cookie中）这在服务器端渲染中是不可访问的（我上面发布的伪代码，它是服务器端，在服务器代码执行过程中不可能进行客户端ajax调用这不适用于此。）这样用户将被视为已注销在这个舞台上。

重定向可能是一个解决方案......但是如果网站也应该为匿名用户工作，并且无论如何都要寻找更好的东西。

SPA应用程序不存在此问题，因为在每次调用内部API之前，它都可以检查JWT并调用刷新JWT令牌。

问题是：由于这个问题，JWT一般不应该（不能）用于多页（传统）应用程序吗？还是有办法解决这个问题？或者这根本不是问题（用户不会经常关闭标签，或者他们希望网站将其注销或重定向等）？

JWT刷新令牌和多页面应用程序

0 个答案: