服务器端oauth：如何处理收到的令牌

Question

这是我第一次完全实现服务器端OAuth（如此处所述https://developers.google.com/identity/protocols/OAuth2WebServer），我对从令牌服务器接收令牌后如何处理令牌感到困惑。我可以看到一些选项

1. 将其发送给用户以进行本地存储并将其发送到数据库。让前端在每个请求的http头中发送它，并将其与数据库中的一个进行比较以进行身份​​验证。

2. 将其发送到数据库并通过jwt或cookie进行其他形式的身份验证。

3. 别的什么？

1将是我的首选方式，但是它有些不对劲...... IDK是什么，虽然2感觉有点浪费，因为我必须想出一个完全不同的auth机制，然后从db中取出令牌然后刷新并正常使用......

此部分应用程序的可接受流程是什么？

Answer 1

首先，您应该决定应用程序的哪个部分将具有OAuth2客户端的角色。如果你有一个React SPA作为前端，我建议你把它作为客户端并使用Implicit grant OAuth2流程（专为浏览器应用程序设计）而不是Auth code grant。这样，SPA启动身份验证，并接收ID令牌（以识别用户）和访问令牌以调用Google services。

然后有一个问题如何在后端识别用户。我会使用ID令牌 - 后端必须检查Google签名，并且令牌的受众是您的应用程序的客户端ID。根据此ID令牌，您可以发出自己的令牌（仅用于识别前端用户），创建后端会话或继续发送每个请求的Google ID令牌。

Answer 2

我认为您需要回答的第一个问题是您使用OAuth令牌的原因是什么。在我们查看该问题之前，让我们了解服务器端OAuth流或授权代码OAuth流通常为您提供的令牌（基于您指定的范围）。

1. 访问令牌：这是一个不记名令牌（意味着如果你有令牌，你有权访问），那就是你在查询提供商的API或试图访问它时使用的令牌提供商的资源。根据用于获取令牌的流，令牌可以具有不同的到期时间。

2. 身份令牌：这是一个签名的JWT令牌，您可以内省并获取有关用户的身份信息，例如用户名，电子邮件等。

3. 刷新令牌：用于续订访问令牌

访问这些令牌可以让你做很多事情：

• 代表用户访问提供商的资源
• 识别用户
• 通过查询提供商的API获取有关用户的更多信息
• 在用户和后端之间建立会话 等

但是当你使用它们时，你需要了解令牌的价值。 例如，服务器端流OAuth提供长期访问令牌，这些令牌应仅存在于trusted客户端（例如后端而不是前端）。如果您的用例需要从前端（被视为low trust客户端）访问提供商的资源，则应使用隐式OAuth流。

关于会话管理，您应该再次了解OAuth访问令牌为持有者提供了某些特权（取决于指定的范围），以便在会话泄露时提供。因此，除非您出于其他原因，否则一般情况下不要将访问令牌用作会话管理cookie。

关于用户身份，这通常是一个非常短期的令牌，所以一旦验证了令牌（签名，状态和到期），那么你应该在后端或签名cookie中缓存用户身份等。