【问题标题】:oauth 2.0 showing authorization page againoauth 2.0 再次显示授权页面
【发布时间】:2012-08-27 19:45:06
【问题描述】:

我是 oauth 2.0 的新手,正在阅读它。我尝试将 oauth 2.0 用于具有 37signals 站点的应用程序,但遇到了问题。现在确定它是否符合设计。任何这里都是我所看到的。

  1. 用户已登录 37signals 网站。
  2. 我的应用程序通过将他重定向到 37signals 站点来启动 oauth 流程
  3. 出现一个授权页面,询问用户是否可以授予对我的访问权限 应用程序。
  4. 用户批准并返回到我的应用程序。 (访问令牌 也可以)
  5. 现在,用户退出 37signals 站点。
  6. 用户尝试使用我的应用程序。我的应用程序通过重定向他来启动 oauth 流程 到 37signals 网站。
  7. 用户使用登录屏幕登录。
  8. 他再次看到授权页面。 不应该跳过这个,因为 用户第一次批准? 或者这是设计的?

无论如何,这对我来说似乎不太友好,即每次注销后都显示批准页面。

我也注意到 Twitter 的类似行为。我最初在使用 nodejs oauth 库时发布了一个类似的问题。然后我认为这是一个一般的 oauth 2.0 问题。 everyauth always triggers authorization

【问题讨论】:

    标签: oauth oauth-2.0 twitter-oauth oauth-provider


    【解决方案1】:

    在初始身份验证时,身份验证提供程序(在本例中为 37Signals)将提供身份验证令牌。与您的应用程序密钥一起,您可以在初始身份验证之后使用用户令牌随后对其进行身份验证。 OAuth 提供者通常会随着时间的推移使身份验证令牌过期,在这种情况下,您需要让您的用户重新进行身份验证。

    【讨论】:

    • 我遇到的问题是授权(请求许可的审批页面),而不是身份验证(登录屏幕)。注销后,我会看到登录屏幕(身份验证),然后再次显示批准页面(授权),尽管我之前批准了该应用程序。
    • 我想知道这是否与您使用的流程有关。 37Signals 支持 Web 服务器和用户代理流。你用的是哪一个?协议文档 (tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4) 的 1.4.1 和 1.4.2 节分别描述了这两者。我正在阅读这篇文章,看看我是否能确定您的问题。
    • 感谢您的链接。我正在做 Web 服务器流程。从 Twitter 网站 - dev.twitter.com/docs/browser-sign-flow 阅读更多内容后,它看起来像设计的那样。从该链接 - 当用户退出时,“请注意,即使用户已经授予对应用程序的访问权限,仍然会显示权限列表。”
    • 在随后的登录尝试中显示权限列表并不让我感到惊讶。但是,我不希望他们每次后续尝试都必须重新授权应用程序。
    猜你喜欢
    • 2014-07-20
    • 2011-12-07
    • 2012-06-19
    • 1970-01-01
    • 2013-10-05
    • 2014-07-20
    • 1970-01-01
    • 1970-01-01
    • 2013-04-06
    相关资源
    最近更新 更多