【问题标题】:How to identify provider for oauth2 redirect_uri callback?如何识别 oauth2 redirect_uri 回调的提供者?
【发布时间】:2015-05-12 23:28:37
【问题描述】:

我试图了解如何正确识别返回授权请求是由哪个提供商发起的。我看到了三种方法:

  • 使用提供商特定的redirect_uri 回调URI。 /oauth2/<provider-name>/callback
  • 以某种方式在 state 参数中编码提供者 ID/名称
  • 在网络会话中存储待处理的提供者 ID/名称
  • 尝试验证所有使用过的提供者的响应

我已阅读 OAuth2 规范的部分内容,但找不到任何讨论它的内容。查看其他客户端实现,似乎提供者特定的 URI 是最常见的解决方案。我错过了什么吗?

【问题讨论】:

    标签: oauth-2.0 openid-connect


    【解决方案1】:

    客户端可能不是多租户的,并且与单个授权服务器紧密集成,因此无需存储提供者标识符,因为只有一个固定的标识符。这可能是没有明显解决方案的原因。

    像您这样的多提供商客户端应该将提供商标识符存储为state 的一部分。这是因为 state 应该受到保护,而特定于提供程序的 redirect_uri 则不受保护。可以针对提供者 B 的回调播放提供者 A 的访问令牌,从而破坏提供者特定回调的目的。

    state 可以通过引用服务器状态或加密 cookie 或通过状态参数的自包含加密结构化值形式的值来保护,因此可以作为一种安全机制来存储提供标识符。

    【讨论】:

    • 感谢您的回答!我正在实施 OpenID 连接,所以我正在阅读 OAuth2 的工作原理。 “播放访问令牌”是指与响应类型代码一起使用的代码吗?但是在 OpenID 连接的情况下,依赖令牌验证可以吗?假设您使用状态或不同的回调区分提供程序以了解在哪里获取令牌以及使用哪个共享密钥。
    • 是的,在 OpenID Connect 中,可以通过查看 id_token 中的 iss 声明来识别(并验证)提供者。是的,当谈到基本客户端配置文件时,播放将使用code 完成,在隐式客户端配置文件中它将是access_token
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-10-28
    • 1970-01-01
    • 2022-01-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多