我有一个客户端 (SPA)/服务器 (REST) 应用程序，我需要对客户端进行身份验证并让它们在资源服务器中保持登录状态。 应用程序通常必须使用位于第三方授权服务器上的外部 OAuth2 服务。 现在的问题是:refresh_token 应该存储在哪里？我有两个想法。
我有意省略了 refresh_token 过期的情况。
假设
- 始终返回有效 token 以响应对任何安全资源的请求和登录请求。
- 与授权服务器的所有通信都必须通过资源服务器，因为需要 client_id 和 client_secret。
第一个场景
- 服务器存储由 token 映射的 refresh_token 并发送 token 给客户端以响应登录请求。
- 客户端使用 token 发出请求。
- 服务器检查 token 是否有效。如果不是，它使用与 token 关联的 refresh_token 生成一个新 token 。现在一分钟(或任何配置的持续时间)，旧 token 映射到新 token ，新 token 映射到 refresh_token 以处理使用旧 token 的排队请求。
- 客户端使用 token 发出请求。
- 服务器检查 token 是否有效。如果不是，它会检查 token 是否映射到新 token 。如果是这样，它的行为就像使用新 token 发送请求一样(请参阅第 3 步)。否则发送 401。
第二种情况
- 服务器发送 token 和refresh_token给客户端响应登录请求。
- 客户端使用 token 发出请求。
- 服务器检查 token 是否有效。如果不是，它会以 401 响应。
- 如果客户端使用 401 状态的响应，它会尝试刷新 token 并使用新 token 发出相同的请求。
我知道这两种解决方案都有其弱点。有什么好的做法适用于这个问题吗？
最佳答案
access-token 和 refresh-token 应该留在它们被获取的地方，特别是如果你的后端没有使用 HTTPS。
没有自己的 REST 后端的 SPA 应该使用 OAuth 隐式流程来获取访问 token 。隐式流不支持刷新 token 。
具有服务器端后端的应用程序应使用授权代码流(您的情况)。授权代码由后端交换以访问和刷新 token ，并且应该保留在那里。您的 REST 后端可以使用 access-token 访问第三方资源，并在必要时使用 refresh-token 更新 access-token。
关于javascript - 使用第三方 OAuth2 服务将 SPA/REST 应用程序的 refresh_token 存储在哪里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27966775/