【问题标题】:OAuth provider with multiple consumer keys for single app具有单个应用程序的多个使用者密钥的 OAuth 提供程序
【发布时间】:2011-09-29 13:38:13
【问题描述】:

我正在开发一个使用 OAuth 的 appengine 应用。当然,我同时处理应用程序的多个版本 - 用于开发的本地版本、暂存版本和部署版本。

要使用这些,我需要三组单独的 OAuth 使用者密钥/秘密,因为身份验证回调是在提供者的站点上定义的。

我想知道提供商是否有办法为给定的应用程序提供多个密钥/秘密 - 这似乎比每次都设置一个新应用程序更有意义。 (当然,这需要提供者实现,但实现起来似乎很自然,我没见过)。

更一般地说,使用什么标准方法来处理这个问题 - 我的猜测是注册多个应用程序并在应用程序中有逻辑来确定它是否处于开发模式、暂存或部署。欢迎任何想法。

【问题讨论】:

    标签: oauth


    【解决方案1】:

    我发现这是 OAuth API 客户端开发人员最烦人的部分之一。提供者没有理由不允许开发人员注册重定向(回调)URI 以进行测试。

    我见过的标准方法是允许您将一个或多个域列入白名单以进行回调/重定向。 Facebook 有一些疯狂的设置,它们允许您通过为应用程序配置文件中的各种链接使用不同的域来“注册”多个域。我没有太多运气。 Twitter 是更好的实现方式之一,可让您注册多个域。

    在 OAuth 2.0(草案 18 或更新版本)中,该主题得到了更好的处理。建议注册完整的 URI,能够注册多个回调并在请求时动态选择您想要的一个。

    要考虑的主要方面是您希望如何使用暂存设置处理权限?您希望能够重复使用现有的批准还是希望将它们分开?此外,如果 API 提供特殊的仅限客户端调用(例如客户端存储或管理工具),您希望阶段版本共享它还是保留它自己的(以便测试不会弄乱生产)。

    最后,提供商应提供完整的开发环境,其中包括 API 客户端的测试设施。大多数人没有。

    【讨论】:

    • 感谢您富有洞察力的回复(我还没有足够的代表来投票)-很高兴看到我不是唯一一个看到问题的人。关于处理权限的问题——我想一个解决方案可以完全解除对不同应用程序变体的批准——这似乎是当今解决方案的自然演变。
    【解决方案2】:

    从 API 提供商的角度来看,您的应用只是一个使用 API 的应用。通常不存在不处理实时生产数据的“暂存”API。无论您正在测试什么,您都是在实时数据上测试它,对吗?

    如果你能够注册几个不同的应用程序,例如不同的回调,那么我认为你的问题已经解决了。我的观点是,将这些东西分开应该是消费者的责任。

    【讨论】:

      猜你喜欢
      • 2023-03-22
      • 2012-09-28
      • 2012-08-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-20
      • 2013-02-23
      相关资源
      最近更新 更多