【问题标题】:Changing Permissions with Google OAuth使用 Google OAuth 更改权限
【发布时间】:2013-12-30 07:50:49
【问题描述】:

我正在升级帐户以使用新的 plus.login 范围,因此我测试了添加一个仅具有 userinfo 范围的用户,然后重新登录并添加了 plus.login。结果是在授权访问面板中引入了一个新条目,而后一个调用返回的访问令牌只有userinfo 权限。我通过进行经过验证的令牌调用以及尝试列出人员来测试这一点。

这是预期的行为吗?如果是,我应该提前撤销旧令牌吗?我看到/revoke 操作是可能的。 Server side removal of Oauth token

更新:Relevant Gist。这是使用 Ruby 的 Omniauth gem。我实际上不确定用户如何在授权访问面板中看到超过 1 个条目,但在这种情况下我可以看到 2 个。昨天测试了各种场景后,我有大约 6 个条目都属于同一个应用程序!请注意,我在任何时候都没有更改客户端 ID,实际上只有一个客户端 ID。

我希望我所描述的情况可以被其他人复制;只需破解 Google 端 URL 以删除 plus.login 范围,然后在保留 URL 原样的同时再次登录。

更新 (2):我还发现了 this gotcha:“您不应请求 userinfo.profile 或 plus.me 与此范围相结合,因为它们已隐式包含在内,并且会为您的用户创建一个令人困惑的权限对话框。”事实上,这不仅仅是一个 UX 权限问题。 Google 似乎实际上不会针对用户存储“plus.me”范围,因此这意味着即使用户已经授予权限,它也会始终显示 OAuth 权限对话框(我认为因为它会进行简单的相等性检查和通知 plus .me 被请求,但不针对用户存储)。

更新(3):关于使用错误登录的错误是由于我的代码执行了类似 user.login || user.signup 不更新登录时的令牌数据。所以现在它在每次登录后更新访问令牌和刷新令牌。 (我仍然不明白为什么每个客户端-用户组合需要多个令牌。)

【问题讨论】:

    标签: oauth-2.0 google-oauth


    【解决方案1】:

    也许您在发布新的令牌之前没有撤销您之前已通过身份验证的客户端的令牌?

    您可以使用以下 JavaScript 演示测试升级范围后撤销是否有效:

    1. 使用this page 进行授权。 (请勿断开授权客户端)
    2. 以升级您的授权using this page, which includes the calendar 范围为例,它具有相同的客户端。
    3. 现在,如果您查看your issued authorizations subtokens page,您会注意到每个客户端对应两个条目。
    4. 通过刷新并单击断开按钮从第二页撤消。
    5. 返回your issued authorizations subtokens page。两套已发行的授权子代币现已不复存在。

    我对此进行了进一步测试并对项目进行了更改,添加了驱动范围。将范围添加到 API 客户端项目并授权其他客户端后,撤销任何令牌将撤销该项目中的所有授权客户端。

    如果您要从其他客户端升级现有的授权凭据,则应在升级现有令牌时撤销旧令牌,以避免出现无法按预期工作的凭据实例。

    但是,正如您从演示中看到的那样,从同一个 API 客户端撤销令牌将撤销额外发布的身份验证令牌,因此您无需担心撤销之前发布的令牌。

    撤销旧令牌(例如,具有 userinfo.email 范围的刷新令牌)的最佳理由是,您以后可能会尝试使用该令牌对新范围进行 API 调用,即使该令牌尚未被升级以包含额外的范围,并可能引入奇怪的错误。

    最后一点:希望用户会更习惯于从Manage apps page on Google+ 查看他们颁发的授权令牌,这可以更好地删除已连接应用程序实例的重复数据。

    【讨论】:

    • 谢谢,这个演示基本上复制了我所困惑的大部分内容,即有第二个条目,因为我认为升级会简单地覆盖它,但我认为这是预期的行为。 (尽管我仍然不确定为什么会返回错误的令牌;我会重新测试。)我仍然有同样的实际问题,即升级现有令牌的最佳做法是什么,因为理想情况下我只想要一个令牌(即使我每次都能用正确的令牌准确地拨打电话,也没有必要)。所以我猜我的服务器应该在升级的令牌回来时撤销“所有其他令牌”?
    • 附加注释添加到答案中,因为我的评论空间不足。
    • 谢谢,这对于确认其他人应该被撤销非常有用。所以听起来你建议当用户点击登录按钮时,我的服务器应该首先尝试撤销任何现有的令牌,并且只有在收到来自谷歌服务器的成功响应时才请求新的令牌。换句话说,在用户请求和应用服务器重定向到 Google 的响应之间发生了服务器到服务器的往返。
    • "其他人应该被撤销" 这仅适用于老客户,应该这样做以避免刷新令牌的行为不符合您的预期。但是,从同一个客户端撤销令牌(例如,您向 API 控制台添加服务以更新您请求的范围,并且您的 clientid/secret 保持不变)将在获得额外令牌后撤销您的新令牌,如演示中所示。
    • 感谢您提供这些详细信息,我还询问了有关“管理应用”页面的后续问题。 stackoverflow.com/questions/15444692/…
    【解决方案2】:

    这听起来不像是正确的行为。您能否从稍后的调用中获取访问令牌并将其插入https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=TOKEN_GOES_HERE - 这将显示它被授权的范围。

    您也在哪个平台上实施?如果你有一个可能有帮助的 sn-p!

    更新:在之前的身份验证后尝试添加 plus.login,我得到了一个新的同意对话,所以看起来一切都很顺利。可能是客户特定的问题?

    【讨论】:

    • 我确实检查了令牌;这就是我所说的验证的意思,它返回了所请求的原始范围(没有 plus.login)。根据要求添加了带有代码的 Gist 链接。
    • 随着更新,之后发生了什么?您是否在访问面板中看到 2 个条目 (t.co/BIv3RN67MK),以及当您全部 /tokeninfo 时返回的范围。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-09-23
    • 2020-10-28
    • 1970-01-01
    • 1970-01-01
    • 2015-07-02
    相关资源
    最近更新 更多