rest - OAuth - 在磁盘上存储什么

Question

TL;DR 在桌面应用程序上使用 google oauth 时，要在磁盘上保存什么以避免重复登录？保存谷歌用户 ID？还是 token ？还是 session ID？

我正在创建一个小型桌面应用程序，它必须对我的 REST API 服务器进行身份验证。为此，我正在使用 google oauth2。

想法是，当桌面应用程序将被验证时，它会生成一些数据，这些数据将发送到我的服务器。服务器将使用从 https://www.googleapis.com/userinfo/v2/me 收到的 google 用户 ID 存储数据。

在第一次运行桌面应用程序时，它会打开默认浏览器，使用我的服务器的 url 并启动本地 http 服务器。然后:

1. 我的服务器会将浏览器重定向到 google(使用 clientid、secret 等)
2. 用户登录，它将使用oauth代码重定向回服务器
3. 服务器使用代码获取 token ，然后是用户配置文件并将 token 和配置文件存储在数据库中，然后使用参数将浏览器重定向到本地主机
4. 桌面应用程序捕获参数并将其存储在磁盘上的文件中

下次桌面应用程序启动时，它只读取参数文件，将生成的数据连同它一起发送到我的服务器

我的问题是:参数应该是什么？谷歌用户 ID？ oauth token ？为此桌面应用程序生成的 session ID？还是别的？

• 当它将是 google 用户 id 时，它可以方便地发送带有用户 id 的数据，其余服务器将按原样将其存储在 db 中。但我认为这不安全
• 当它将成为 token 时，其余服务器必须针对每个请求还使用 token 从 google 获取用户配置文件。恕我直言，随每个请求发送 token 也不安全
• 生成 session ID 意味着将其与用户和 token 一起存储在服务器上，桌面应用程序将只存储它并随每个请求一起发送。但我不知道这样做是否安全

Answer 1

正如软件开发中的通常情况一样，根据需求，您有多种选择。

强制性要求是您的客户端(桌面)应用程序需要向您的 REST API 发送一些内容，以便该 API 最多可以执行两个决定:

1. 确定用户是谁。
2. 确定用户是否有权执行当前请求的操作。

如果所有经过身份验证的用户都可以访问完全相同的一组操作，那么第二步可能不适用，因此我将介绍这两种情况。

另请注意，对于第一步，发送 Google 用户 ID 不是一个有效的选项，因为其他方可以获得该信息，并且不能确保用户确实通过身份验证来使用您的申请。

选项 1 - 身份验证_{无细粒度授权}

始终发送 id_token 或将该 token 与您的自定义 session 标识符交换都满足前面的要求，因为 id_token 包含明确指示用户经过身份验证的受众使用您的应用程序并且 session 标识符是由您的应用程序生成的，因此它也可以确保这一点。对您的 API 的请求需要使用 HTTPS，否则 token 或 session ID 很容易被攻击者捕获。

如果您使用 id_token 替代方案，您需要考虑 token 将过期；为此，再次提供一些选项:

• 再次重复验证过程；如果用户仍然有一个 session ，它确实会更快，但您仍然必须打开浏览器、本地服务器并重复整个步骤。
• 在进行第一次身份验证时请求offline_access。

使用最后一个选项，您应该得到 refresh token即使在第一个 id_token 过期后，您的应用程序也可以通过这种方式识别用户。我说应该，因为谷歌似乎做的事情与规范有点不同，例如，获取刷新 token 的方式是通过 providing access_type=offline而不是 offline_access from OpenID Connect .

就个人而言，我会选择 session 标识符，因为您可以更好地控制生命周期，而且它也可能更简单。

选项 2 - 身份验证 + 细粒度授权

如果您的 REST API 需要一个细粒度的授权系统，那么最好的方法是使用 Google 对您的用户进行身份验证，然后拥有一个符合 OAuth 2.0 标准的授权服务器，该服务器会颁发特定于您的 API 的访问 token 。

对于授权服务器实现，您可以:

• 自行实现或利用开源组件
  ⤷ 可能会耗时、复杂并且安全风险的缓解将全部落在您身上

• 使用第三方 OAuth 2.0 作为服务授权提供程序，例如 Auth0
  ⤷ 容易上手，取决于使用量(Auth0 上的免费计划 goes up to 7000 users )它会花钱而不是时间

_{披露:我在 Auth0 工作。}