是否可以通过在调用回调 URI 之前显示自定义同意屏幕来扩展 OpenID Connect 流程？
这是不安全的，与 OIDC 的目标背道而驰
作为向您提供的 OIDC 的消费者，允许您控制同意的外观，可以向最终用户显示一件事，然后让 OIDC 提供者完全用另一件事签署 JWT 声明.
可能你还不明白你只是乙方和三方的关系。
甲方是最终客户端，它同意丙方让乙方访问丙方控制的身份数据。
如果您（B 方）获得许可，那么您就知道最终客户端的身份，OIDC 将在 C 方生成的 JWT 中授予您额外的数据。 JWT 是 C 方用来向您保证他们执行 Authn 以证明 A 方是他们声称的身份、他们是真实的并向您保证 B 方的机制。
所以你不能也不应该影响这个过程。
您不应该在生成 JWT 之前假设身份，因此影响与身份相关的任何事情都会破坏安全模型，如果您自己影响了结果，您怎么能确定呢？这是荒谬的。
您不应该能够影响呈现给最终客户端的权限，因为最终客户端甚至还没有决定他们是否授予您权限！
C 方知道最终客户是谁，他们已经建立了关系。
您正在使用 OIDC 介入并利用这种受信任的关系，因此您可以相信最终客户就是他们声称的人，因此您可以从 C 方获取有关最终客户的一些个人身份信息。
即 OIDC 和您在流程中的角色，需要明确的是，在在 OIDC 流程完成并且您被授予甚至拥有包括终端客户。
tos_uripolicy_uri这是要求同意客户服务条件吗？
这是为了知情同意。
最终客户端仍将显示相同的同意屏幕，也许OIDC 提供商将调整 UI 以显示指向您的服务条款或隐私政策的链接。
例如，OIDC 协议之外的 Okta 允许您创建用于 OIDC 的应用程序，并在该应用程序配置 it has these attributes。
但在 OIDC Okta 期间，根本不会调整 UI 以提示用户接受这些条款，甚至 last year Okta asked a client 添加一个定制字段来表示同意。
我需要重申，作为 OIDC 消费者，在您获得同意之前，您不能也不应该能够直接自定义 OIDC 流程。但是您可能会找到同意为您配置其 UI 的 OIDC 提供商。这取决于他们，最终客户与身份提供者有关系，您实际上是在实践中请求进入中间并利用它。
现在在商业上是完全不同的情况。您向 OIDC 提供者付款，这使 OIDC 提供者在经济上更有动力为您提供帮助。这也意味着，如果 OIDC 提供商不更多关心保护最终客户的身份而不是与支付账单的一方合作，那么 OIDC 的安全特性就是利益冲突。此外，最终用户甚至可能没有意识到他们与 OIDC 提供商建立了身份和信任关系，他们甚至可能认为这只是 2 方关系而不是 3 方关系，他们决定是否共享他们的身份与你。这也是为什么 B 方（您）的开发者误解了 3 方关系，并根据 OIDC 协议的安全特性假设他们拥有比应有的更多控制权的原因。
这种商业影响、终端客户混淆和实施误解导致 OIDC 协议无法提供 3 方模型的预期安全特性，并破坏了对它的整体需求。在大多数情况下，您不需要 OIDC，特别是如果 3 方模型不方便并且您希望更多地影响同意并且 OIDC 提供商不提供此功能，并且您可能期望并希望 OIDC 不提供更多元素，OIDC 可能不是您的业务所需要的。