使用访问令牌 + OAuth 提供者处理用户会话答案

【问题标题】：Handle user session with access token + OAuth provider使用访问令牌 + OAuth 提供者处理用户会话
【发布时间】：2022-01-06 20:42:20
【问题描述】：

我正在构建一个具有基本客户端-服务器架构的 Web 应用程序。前端使用 react (nextjs) 运行，后端在 rails 上。但是，问题将更多地是关于前端的身份验证/授权 + 会话处理的流程。

我正在使用 Oauth 提供者来处理 身份验证，但不需要他们的任何授权，因为我不需要 oauth 提供者的资源（例如驱动器、日历等）。 )

对于授权，因为我想访问我的 API 的资源，它是 API 本身处理客户端（前端）向 rails API 发出的任何请求的授权。

对以下问题很重要的实施细节：

我使用 JWT 作为访问令牌（由我的 API 生成的那些），我只是使用仅在我的 API 上可用的密钥对其进行签名，因此从前端的角度来看访问令牌是不可读的。

在前端，它是一个 React 应用程序，我使用以下包来处理 OAuth 流程google-react-login

从 Google（OAuth 提供商）收到的信息、使用什么 1- 我收到（除其他外）来自 Google 的 IdToken 和访问令牌。此外，我显然应该收到一个刷新令牌（我没有看到）。对于我的用例，我只需要来自 Google 的 idToken 对吗？

撤销刷新令牌（注销），重新登录流程？

2- 据我了解，出于安全原因，访问令牌需要短暂存在。所以我需要向我的客户端应用程序返回一个刷新令牌，以便能够经常生成新的访问令牌。但是，一旦刷新令牌达到其到期时间，我是否需要注销用户并提示他通过 Google 重新登录并基本上重做步骤 1 到 5（请参阅图 1）？

如何通过访问令牌维护会话

3- 从前端的角度来看，我可以假设仅仅拥有一个刷新令牌就意味着用户已登录吗？一旦服务器撤销访问令牌和刷新令牌，这意味着用户已注销，我需要为未经身份验证的用户输出 Web 应用程序的视图？这意味着在每次重新加载页面后，我都需要检查是否存在访问和刷新令牌？

谢谢

【问题讨论】：

与人们的看法相反，cookie 是一个简单的 ID，可以被暴力破解并允许黑客进入任何用户帐户。因此请记住，可能会发生劫持，这或多或少不安全，但会增加双重身份验证，从而确保您的安全。
是的，这就是我使用短期访问令牌来授权用户向我的 API 发出请求的原因。此外，该令牌使用一种算法进行编码，除了令牌只有很短的生存时间这一事实之外，该算法很难进行暴力破解。通过双重身份验证，您是在谈论 google 身份验证？

【解决方案1】：

我认为您可以通过一件事来提高安全性并降低复杂性 - 用自定义 OAuth2 服务器替换发布您自己的 JWT 令牌。此 OAuth2 服务器可以使用 Google 作为身份验证提供程序。这样一来，您就不会知道 Google，它只会使用您自己的 OAuth2 服务器。

然后您可以决定如何使用它 - 前端是 OAuth2 客户端还是后端。

如果您选择前端，您将使用 PKCE 的身份验证代码流（作为公共客户端）。前端将使用 access_token 授权其对后端的请求。这样，前端将使用隐藏的 iframe 处理会话。请参阅OpenID Connect Session Management RFC。

如果您选择后端，您将使用身份验证代码流（带有客户端密码）。这样，您的后端可以使用 cookie 来维护会话（具有安全、仅限 HTTP、SameSite 选项）。

您可以阅读OAuth 2.0 for Browser-Based Apps RFC 了解当前的最佳做法。

【讨论】：