为什么 OpenID Connect 让客户端为另一个客户端启动身份验证答案

【问题标题】：Why OpenID Connect let a client initiate authentication for another client为什么 OpenID Connect 让客户端为另一个客户端启动身份验证
【发布时间】：2022-01-13 17:31:23
【问题描述】：

我在 Keycloak 中使用 OpenID Connect 作为身份验证解决方案，我刚刚遇到了以下场景。

客户端A向授权服务器发送授权请求，并在该请求中提供客户端B的redirect_url。
授权服务器对用户进行身份验证并将用户重定向到提供的redirect_url（用于客户端B）和authentication_code。
客户端B 使用自己的client_id 和秘密与授权服务器通信并获取其令牌。

我想知道为什么 OpenID Connect 允许这样做过程中，一个客户端为另一个客户端发起认证是正常的吗？为什么发出的authentication_code没有绑定到发起认证的客户端，为什么authentication_code可以被其他客户端和其他client_id一起使用？

注意：我知道redirection_url 的有效性将在该过程中进行检查，但我想知道为什么授权码不绑定到 client_id 本身。

【问题讨论】：

标签： oauth-2.0 keycloak openid-connect

【解决方案1】：

如果在 Keycloak 中确实有可能，那么这是实现的问题，而不是规范的问题。 4.1.2. 部分中的 Oauth 规范为授权代码指明了这一点：

授权码绑定到客户端标识符和重定向URI。

对于重定向 URI，它也应该经过验证，并且客户端 A 应该能够使用客户端 B 的重定向 URI，前提是该其他重定向 URI 已被客户端 A 列入白名单。

Proof Key for Code Exchange 也可以防止像您在此处描述的那样使用 Oauth 流。

【讨论】：

感谢您的宝贵回答，但我不明白您对重定向 URI 的描述，如果我在客户端 A 中接受客户端 B 的重定向 URI，授权绑定发生了什么客户A的代码？您的意思是当我在客户端A 的白名单中定义客户端B 的重定向URI 时，那么客户端B 也可以使用该授权码吗？当提到可能时，您能否参考协议？
授权码仍应绑定到客户端 A，但是，可能出于某种奇怪的原因，您仍然希望将用户重定向到客户端 B。当然，客户端 B 仍然无法将代码交换为令牌，因为代码绑定到客户端 A。我在答案中的意思是，通常客户端 A 根本不应该能够使用客户端 B 的重定向 URI，因为应该根据客户端 A 的白名单验证 URI。从技术上讲，可以将客户端 B 的 URI 添加到该白名单中，但我没有看到这样做的正当理由。