使用 openid connect 时如何确保客户端服务的 GDPR/ToS 合规性？

Posted 2023-02-19

【中文标题】使用 openid connect 时如何确保客户端服务的 GDPR/ToS 合规性？

【英文标题】：How to ensure GDPR/ToS compliance of client service when using openid connect?

【发布时间】：2022-01-02 08:49:57

【问题描述】：

背景

我们的网络应用需要用户主动同意我们的条款和条件。当用户登录时，我们会检查他们是否已经同意最新版本的条件。如果未提供此信息，则用户需要同意并且将无法访问应用程序的任何部分或其 API（尽管已正确登录）。

问题

我们正在使用 OpenID Connect 进行身份验证。我发现以下属性表明您可以要求同意自定义条件（请参阅here）：

tos_uri policy_uri

这是否意味着需要同意客户服务条件？

我应该为其创建自定义声明吗？ （-> ToS 可能会有新版本，需要重新批准。）

或者：是否可以通过在调用回调 URI 之前显示自定义同意屏幕来扩展 OpenID Connect 流程？

【问题讨论】：

从开发人员的角度来看，OIDC 是一个客户端范围，因此我们也需要知道您正在连接的 OIDC 提供商，以了解可用的功能和正在使用的变体。例如，使用 AWS Cognito 的 OIDC 使用两个不同的 JWT，并且仅支持 RSA，但 OIDC 流程只是 Authn 流程的一小部分。 Okta 支持 HMAC JWT，Azure 同时支持 RSA 和 ECDSA，并且大多数浏览器流都在 OIDC 协议之外。而且它们都不允许您生成 JWT 或控制 OIDC 支持的部分或可用的功能，您只能使用 OIDC。那么您可以使用 OIDC 的哪些部分？

【参考方案1】：

是否可以通过在调用回调 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 可能不是您的业务所需要的。

【讨论】：

感谢您的广泛回答。我可以看到这并不真正符合我们的需求，因此我们需要在我们这边实现一个额外的登录步骤。