OAuth - 存储在磁盘上的内容

时间:2016-10-29 06:50:00

标签: rest oauth google-oauth desktop-application

TL; DR在桌面应用上使用google oauth时,要在磁盘上保存哪些内容以避免重复登录?保存Google用户ID?还是令牌?还是会话ID?

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

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

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

  1. 我的服务器会将浏览器重定向到谷歌(包括clientid,secret等)。
  2. 用户登录后,将使用oauth代码
  3. 将其重定向回服务器
  4. 服务器使用代码获取令牌,然后使用用户配置文件并将令牌和配置文件存储在db中,然后使用参数重定向浏览器到localhost
  5. 桌面应用程序捕获参数并将其存储在磁盘上的文件中
  6. 下次桌面应用程序启动时,它只读取参数文件,将生成的数据发送到我的服务器

    我的问题是:参数应该是什么?谷歌用户ID? oauth令牌?此桌面应用生成的会话ID?或其他什么?

    • 当它是Google用户ID时,它可以方便地使用用户ID发送数据,其余服务器只会将其存储在db中。但我认为这不安全
    • 当它将成为令牌时,其余服务器必须与每个请求一起从谷歌获取用户配置文件和令牌。并且imho在每次请求时发送令牌都不是安全的
    • 生成会话ID意味着将其与用户和令牌存储在服务器上,桌面应用程序将只存储它并随每个请求发送它。但我不知道这样做是否安全

3 个答案:

答案 0 :(得分:1)

正如软件开发中的情况一样,根据要求,您可以选择几种方法。

强制要求是您的客户端(桌面)应用程序需要向REST API发送内容,以便API最多可以执行两项决策:

  1. 决定用户是谁。
  2. 确定用户是否有权执行当前请求的操作。
  3. 如果所有经过身份验证的用户都可以访问完全相同的操作集,则第二步可能不适用,因此我将介绍这两种情况。

    另请注意,对于第一步,发送Google用户ID不是有效选项,因为该信息可以由其他方获取,并且不能确保用户进行身份验证以使用您的应用

    选项1 - 没有细粒度授权的认证

    始终发送id_token或与您的自定义会话标识符交换该令牌都符合之前的要求,因为id_token包含一个明确指示用户使用您的应用程序和会话进行身份验证的受众标识符由您的应用程序生成,因此它也可以确保。对API的请求需要使用HTTPS,否则攻击者可能很难捕获令牌或会话ID。

    如果您使用id_token替代品,则需要考虑令牌将过期;为此,再次提出几个选择:

    • 再次重复身份验证过程;如果用户仍然有会话,它确实会更快,但你仍然需要打开浏览器,本地服务器并重复整个步骤。
    • 在进行第一次身份验证时请求offline_access

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

    就个人而言,我会使用会话标识符,因为您可以更好地控制生命周期,也可能更简单。

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

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

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

    • 自己实施或利用开源组件
      可能耗费时间,复杂并且安全风险的缓解都会落在你身上

    • 使用第三方OAuth 2.0作为服务授权提供商,例如Auth0
      易于上手,具体取决于使用量(Auth0 goes up to 7000 users上的免费计划),这将花费您的金钱而不是时间

      < / LI>

    披露:我在Auth0工作。

答案 1 :(得分:0)

为每个请求发送access_token应该没有问题,因为它们是为此目的而创建的,因此很短暂。您可以使用Google Authorization Server endpoint to verify a token代替用户来执行用户个人资料请求。

答案 2 :(得分:0)

如果您仅依靠Google进行身份验证,请参阅以下工作流程:

  1. 客户端(桌面应用程序,在您的情况下)检索到 Google id_token跟随用户登录,然后将其发送给 服务器
  2. 服务器验证所述令牌的完整性并提取用户的配置文件数据;这可能意味着在Google的终端上进行简单的GET验证此令牌:https://www.googleapis.com/oauth2/v3/tokeninfo?id_token={0}
  3. 在后续请求中,除了用户的登录过程将自动化(因为他已获得权限和所有权限)之外,没有什么可以真正改变,因此更快。 @danielx是对的,每次发送令牌都没有问题。