背景
我们的网络应用程序要求用户主动同意我们的条款和条件。当用户登录时，我们会检查他们是否已经同意最新版本的条件。如果不这样做，用户需要同意，并且将无法访问应用程序或其API的任何部分(尽管已正确登录)。
问题
我们正在使用OpenID Connect进行身份验证。我发现以下属性建议您可以要求同意自定义条件(请参阅此处)：
tos_uripolicy_uri
这是为了要求同意客户服务条件吗？
我应该为它创建一个自定义索赔吗？(->ToS可能会获得新版本，需要重新批准。)
或者：在调用回调URI之前，是否可以通过显示自定义同意屏幕来扩展OpenIDConnect流？
在调用回调URI之前，是否可以通过显示自定义同意屏幕来扩展OpenID Connect流？
这是不安全的，违背了OIDC 的目标
作为向您提供的OIDC的消费者，允许您控制同意书的外观，可以向最终用户展示一件事，然后让OIDC提供商完全用其他东西签署JWT声明。
可能你还没有意识到你只是乙方和三方的关系。
甲方是同意乙方访问丙方控制的身份数据的最终客户。如果您(乙方)获得了许可，那么您就知道了最终客户的身份，OIDC将在C生成的JWT中向您授予额外的数据。JWT是丙方用来向你保证他们做Authn是为了证明甲方是他们声称的人，他们是真实的，他们向你保证乙方。
因此，你不能也不应该影响这个过程。
在JWT产生之前，你不应该假设身份，因此影响任何与身份相关的事情都会破坏安全模型，如果你自己影响了结果，你怎么能放心？这是荒谬的。
您不应该影响最终客户的权限，因为最终客户甚至还没有决定是否授予您权限！
丙方知道最终客户是谁，他们之间已经建立了关系。您正在使用OIDC来介入并利用这种信任关系，这样您就可以信任最终客户是他们所声称的人，这样您也可以从C方获得一些关于最终客户的个人身份信息。
这就是OIDC和您在流程中的角色，需要明确的是，在OIDC流程完成后的之前，您没有任何角色或权限，您甚至可以拥有包括最终客户在内的角色。
tos_uripolicy_uri这是为了要求同意客户服务条件吗？
这是为了知情同意。
最终客户端仍将显示相同的同意屏幕，OIDC提供商可能会调整UI以显示指向您的ToS或隐私政策的链接。
例如，在OIDC协议之外，Okta允许您创建一个用于OIDC的应用程序，并且在该应用程序配置中，它具有这些属性。
但在OIDC期间，Okta根本没有调整UI以提示用户接受这些条款，甚至在去年，Okta还要求客户添加一个定制字段来表示同意。
我需要重申，作为OIDC消费者，在获得同意之前，您不能也不应该直接定制OIDC流程。但您可能会发现OIDC提供商同意为您配置他们的UI。这取决于他们，终端客户与身份提供者有关系，你实际上是在要求介入并利用这一点。
现在的商业环境完全不同了。您向OIDC提供商付款，这使OIDC提供商在经济上有动力帮助您。这也意味着，如果OIDC提供商不更关心保护最终客户的身份，而不是与支付账单的一方合作，那么OIDC的安全特性就是利益冲突。此外，最终用户可能甚至没有意识到他们与OIDC提供商建立了身份和信任关系，他们甚至可能认为这只是双方关系，而不是三方关系，他们决定是否与您共享他们的身份。这也是为什么乙方(您)的开发人员误解了三方关系，并基于OIDC协议的安全特性认为他们拥有比他们应该拥有的更多的控制权。
这种商业影响、最终客户的困惑和实施误解导致OIDC协议没有提供第三方模型的预期安全特性，并破坏了对它的整体需求。在大多数情况下，你不需要OIDC，特别是如果第三方模式不方便，你希望更多地影响同意，而OIDC提供商不提供这一点，也许OIDC没有提供更多您期望和想要的元素，OIDC可能不是您的业务所需要的。