在哪里使用第三方OAuth2服务存储SPA / REST应用程序的refresh_token？

Question

我有一个客户端（SPA）/服务器（REST）应用程序，我需要对客户端进行身份验证并让他们在资源服务器中登录。 应用程序通常必须使用位于第三方授权服务器上的外部OAuth2服务。 现在的问题是：应该存储refresh_token的位置？我有两个想法。

当refresh_token到期时，我故意省略这种情况。

假设

• 始终返回有效令牌以响应对任何安全资源和登录请求的请求。
• 与授权服务器的所有通信都必须通过资源服务器，因为需要client_id和client_secret。

第一个场景

1. 服务器存储由令牌映射的refresh_token，将令牌发送到客户端，并响应登录请求。
2. 客户端使用令牌发出请求。
3. 服务器检查令牌是否有效。如果不是，则使用与令牌关联的refresh_token来生成新令牌。现在持续一分钟（或任何配置的持续时间）旧令牌被映射到新令牌，新令牌被映射到refresh_token以处理带有旧令牌的入队请求。
4. 客户端使用令牌发出请求。
5. 服务器检查令牌是否有效。如果不是，则检查令牌是否映射到新的令牌。如果是这样，它的行为就像使用新令牌发送请求一样（参见步骤3）。否则发送401。

第二个场景

1. 服务器将令牌和refresh_token 发送给客户端，并响应登录请求。
2. 客户端使用令牌发出请求。
3. 服务器检查令牌是否有效。如果没有，它会回复401。
4. 如果客户端使用401状态的响应，它会尝试刷新令牌并使用新令牌发出相同的请求。

我知道这两种解决方案都有其缺点。是否有适用于此问题的良好做法？

Answer 1

访问令牌和刷新令牌应保留在获取它们的位置，特别是如果您没有为后端使用HTTPS。

没有自己的REST后端的SPA应该使用OAuth隐式流来获取访问令牌。隐式流不支持刷新令牌。

使用服务器端后端的应用程序应该使用授权代码流（您的情况）。授权代码被交换以通过后端访问和刷新令牌，并应保留在那里。您的REST后端可以使用访问令牌访问第三方资源，并使用刷新令牌在必要时续订访问令牌。

Answer 2

第二种情况在我看来是最可行的。首先，您的授权服务器不必与资源服务器相同。您只能使用刷新令牌从授权服务器获取新的访问令牌。但授权服务器和资源服务器都可以在同一台服务器上实现。

第一个场景中的客户端如何获取新的访问令牌？它正在请求资源（步骤3），并且不期望获得新的令牌。

我会在客户端将刷新令牌存储在浏览器本地存储器中。这不是很安全，但可能是你能做到的最好的。