如何使用 OAuth2 静默刷新过期的 JWT 令牌？答案

【问题标题】：How to silently refresh expired JWT token with OAuth2?如何使用 OAuth2 静默刷新过期的 JWT 令牌？
【发布时间】：2017-09-20 19:12:12
【问题描述】：

我们决定从 Hazelcast 共享会话切换到使用 OAuth2 进行无状态 JWT 身份验证/授权，并发现了一个不适合我们下面描述的基础架构的问题。

因此，我们有多个独立系统 (scs)，可以通过直接链接访问，即 mysite.com/scs1 和 mysite.com/scs2。

每个 scs 都有自己的 UI 和 BackEnd，但“会话”（通过无状态 JWT 授权实现）必须在多个 scs 中有效。

OAuth2 授权服务器是专用服务器 (UAA)。在 OAuth2 术语中，每个 scs 都是一个资源服务器。

假设用户已登录 scs1（通过 UAA）并获得 TTL=10 分钟的 JWT 和 TTL=30 分钟的 RefreshToken。然后他将该选项卡留在浏览器中 15 分钟。 JWT 已过期，但该选项卡仍包含来自 scs1 的上一页。用户点击该页面上的链接，该链接随后进入 mysite.com/scs3。

scs3 收到请求，检查 JWT 并发现它已过期。但是我们有一个可以刷新 JWT 的 RefreshToken（仍然存在 15 分钟）。

是否可以从 scs3 返回一个要求浏览器转到 UAA 并静默刷新 JWT 的响应？

也许某种 REDIRECT 到 /uaa/authorization 能够添加 RefreshToken 标头？

【问题讨论】：

标签： authentication oauth-2.0 jwt microservices refresh-token

【解决方案1】：

我们终于找到了如何在我们的案例中处理令牌刷新。

JWT 的 TTL=10 分钟 RefreshToken 的 TTL=30 分钟

嵌入在我们网站每个页面中的 JavaScript 每 8-9 分钟刷新一次 JWT。因此，当用户在其浏览器中打开标签页时，刷新过程将无缝进行。

极端情况是用户：

打开标签 mysite.com/scs1
登录
关闭标签
等待 15 分钟。 JWT 过期了，RefreshToken 还活着。
打开新标签并输入 mysite.com/scs1 或 scs2 等。

此时 BackEnd 只接收过期的 JWT。所以 BackEnd 将用户重定向到专用网页 /try-refresh?uri=mysite.com/scs1

try-refresh 页面仅包含尝试刷新令牌并在成功的情况下将用户重定向回 uri 参数的地址的 javascript

【讨论】：