Fatal编程技术网
  • authentication/
  • Authentication 多个网站如何从同一OpenID用户/标识获得相同的唯一标识符？

Authentication 多个网站如何从同一OpenID用户/标识获得相同的唯一标识符？

authentication openid

Authentication 多个网站如何从同一OpenID用户/标识获得相同的唯一标识符？,authentication,openid,Authentication,Openid,我们为网站提供了一个后端（RESTful）服务，该服务依赖于在多个不相关的网站上唯一标识同一用户。我们一直使用电子邮件地址作为唯一标识符，但并非所有网站都使用电子邮件地址，特别是当这些网站使用OpenID身份验证时 那么，OpenID是否提供了在多个依赖方之间相同的唯一标识符（如果用户使用相同的OpenID进行身份验证） 如果是这样的话，如果目标是多个不相关的网站在每个网站都有相同的OpenID用户时提供相同的标识符，那么我们将如何指导一系列独立网站为其每个用户提供用户标识符 另外，我们的目标是

我们为网站提供了一个后端（RESTful）服务，该服务依赖于在多个不相关的网站上唯一标识同一用户。我们一直使用电子邮件地址作为唯一标识符，但并非所有网站都使用电子邮件地址，特别是当这些网站使用OpenID身份验证时

那么，OpenID是否提供了在多个依赖方之间相同的唯一标识符（如果用户使用相同的OpenID进行身份验证）

如果是这样的话，如果目标是多个不相关的网站在每个网站都有相同的OpenID用户时提供相同的标识符，那么我们将如何指导一系列独立网站为其每个用户提供用户标识符

另外，我们的目标是让使用我们的API的开发人员尽可能地轻松地完成这项工作。因此，如果您知道任何好的API文档已经解决了这一问题，那么指向它的链接将非常有用。

在不了解您的web服务或其编写语言的情况下，我不确定我的答案会有多大帮助，因为它将相当一般，技术性较差

响应标识/授权请求的OpenID提供商将使用“声明的ID”和“标识”以及请求的任何“属性交换”进行响应。属性交换信息可以是电子邮件/用户名/语言/realname/等您正在查找的内容

Google（作为OpenID提供商）支持查询适当数量的属性交换信息，并在其文档中提供了一个列表：

OpenID标识对用户来说应该是唯一的，但即使是由同一提供商发布的，也不能在不同的网站上交叉标识。（它可以是发布给RP的唯一定向id）。 更多信息请参见此处：

综上所述，作为API的设计者，您完全有理由定义使用Web服务所需的某些信息（即电子邮件地址）。然后将其留给希望使用您的Web服务以某种方式获得该信息的各方（直接询问用户，或通过属性交换等）

有关OpenID的更多信息，我将查看他们的网站，特别是规范和库：

具有一些良好文档作为起点的库包括：

  • JOpenID（Java）：
  • LightOpenID（PHP）：
直接实现OpenID身份验证不适用于后端Web服务，因为最终用户没有参与（即无法提供凭据）

为了满足您在各种第三方网站上识别同一用户的要求，您可能需要成为OpenID提供商。然后提供进一步的API，允许用户在第三方网站上链接到您管理的OpenID配置文件中

而不是身份的实际提供者。。。与第三方共享OpenID身份可能是一个潜在的安全/隐私问题，或者至少违反OpenID规范（该规范将交换描述为RP和OP之间的共享秘密）。尽管这可能超出了您想要做的范围，但作为OpenID提供商至少可以消除许多隐私问题，因为用户必须明确选择加入

我不知道有哪种API能够在没有直接用户交互的情况下处理跨多个第三方网站的唯一标识用户。我编写的大多数Web服务要么需要提供直接用户凭据（用户知道该凭据），要么只需将用户标识为特定客户端的唯一用户。在后一种情况下，用户身份验证并不总是必要的，客户机可以进行全面身份验证，然后提供自己的唯一ID来跟踪用户，从而使Web服务对用户的实际构成视而不见。不幸的是，您的需求似乎不适合这些常见场景

当你设计API时要考虑的最后一件事…

向第三方提供唯一可识别的信息（即电子邮件地址）可能会引起互联网隐私圈的一些关注。特别是如果从交易中获得任何财务收益（广告/直接支付/等），或者如果信息的使用未知/不安全或不受欢迎。

您可能希望确保您的目标客户（您的Web服务的消费者）在其术语中有正确的术语，或者能够为其用户提供足够的权限，允许他们选择不提交到您的服务中。并且清楚地说明你在用这些信息做什么

这类问题可能会阻碍API的接受，因此值得考虑