Question

我目前正在为网站实施OpenID身份验证。在测试过程中，我注意到Google接受了不同版本的Google个人资料ID，例如：

有趣的是，验证的ID也不同（对于上面的样本，相同的顺序）：

当然，这使得查找关联的用户帐户非常困难，更不用说不可能了。有趣的是，所有上述ID都适用于Stackoverflow。所以我认为在我的实现中我必须要有一些规范化步骤 - 或者做一些专门的伏都教来完成事情。

看7.2 Normatlization of the OpenID Authentication spec我发现了这个：

URL标识符必须在检索其内容时通过以下重定向进一步标准化，并最终将[RFC3986]的第6节中的规则应用于最终目标URL。该最终URL必须由依赖方记录为声明的标识符，并在请求身份验证时使用。

以下重定向的声明ID并没有多大帮助，因为我还有两个不同的ID：

查看已验证ID的重定向更有帮助，但我总是最终得到这个：

https://profiles.google.com/stefan.fussenegger

好的，看起来我应该遵循经过验证的ID的重定向，而不是声明的ID。

现在的问题：遵循声明/验证ID的重定向是否安全，例如在搜索DB之前如此：

do {
  user = lookup(verifiedId)
  if (user is null)
    response = fetchUrl(verifiedId)
    if (response.location is null) {
      break # no redirect, jump out of loop, unknown user
    } else {
      verifiedId = response.location # use redirect location
    }
} while (user is null)

return user;

如果是，我怀疑这不仅应该在查找用户时进行，还应该在存储新ID时进行，对吧？

（如果我真的应该遵循重定向，我还有另外一个关于潜在恶意重定向的问题，但是必须等到我得到这个问题的答案。无论如何都可能过时了。）

Answer 1

Open ID 2.0说在发现期间，

URL标识符必须在检索其内容时通过以下重定向进一步标准化，并最终将[RFC3986]的第6节中的规则应用于最终目标URL。该最终URL必须由依赖方记录为声明的标识符，并在请求身份验证时使用。

因此，根据这一点，您应该使用用户提供的标识符并通过以下重定向＆amp;来标准化它。遵循正常的URL规范化程序。

结果被视为“声明的标识符”（CI）。接下来，你将进行协会舞蹈，并确定这种说法是否属实。

注意 - 某些提供商拥有“众所周知的”OpenId Provider（OP）网址，例如Google。如果您注意到StackOverflow的登录过程，则只需点击Google按钮即可填写表单。在此变体中，“众所周知的”OP URL不是用户CI。用户未向您提供CI。您需要等到完成身份验证之后，Google会告诉您该用户是谁。

此时（在从OpenId Provider收到成功的关联回调之后），您将拥有该用户的标识符。根据{{1}}和openid.claimed_id，如果您正在使用扩展程序执行某些操作（我对规范的这个方面不是很熟悉）

现在您应该将openid.identity存储在您的最后 - 这将是此用户唯一的标识符。这可能与用户最初提供给您的不同。它可能与您最终的位置不同（在对用户提供的标识符进行重定向之后）。 OpenID提供商拥有最终决定权。

关于用户提供的标识符上的以下重定向的安全性。这里不应该有问题。重定向允许用户将身份验证委派给他们选择的提供商。无论重定向引导您，您最终都会要求OpenId Provider与您建立关联。当您提出此请求时，您将提供（标准化的）声明的标识符，并且提供商可以决定他们是否希望对声明的标识符负责，并且他们将（以某种方式以他们无限的智慧）授权用户拥有此声称的所有权标识符

回到谷歌，Google最终会提供的声称标识符与上面的示例完全不同。他们使用的示例是openid.claimed_id（section 9.1）。

希望有帮助...

Answer 2

在这种情况下，我使用电子邮件作为唯一标识符。您可以通过Google申请，请参阅http://code.google.com/intl/en/apis/accounts/docs/OpenID.html#Parameters

如何或何时关注重定向的OpenID？

2 个答案: