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

Question

我目前正在为网站实现 OpenID 身份验证。在测试期间，我注意到 Google 接受不同版本的已声明 Google 个人资料 ID，例如:

http://www.google.com/profiles/stefan.fussenegger

http://profiles.google.com/u/0/stefan.fussenegger/about

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

https://profiles.google.com/stefanfussenegger

有趣的是，经过验证的 ID 也不同(对于上面的示例，相同的顺序):

http://www.google.com/profiles/stefan.fussenegger

https://profiles.google.com/stefanfussenegger

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

https://profiles.google.com/stefanfussenegger

当然，这使得查找关联的用户帐户变得相当困难，并不是说不可能。有趣的是，上述所有 ID 都适用于 Stackoverflow。所以我认为在我的实现中必须有一些规范化步骤 - 或者 SO 做了一些专门的巫术来把事情弄清楚。

看 7.2 Normatlization of the OpenID Authentication spec我找到了这个:

URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of [RFC3986] to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.

对声明的 ID 进行重定向并没有太大帮助，因为我仍然有两个不同的 ID:

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

https://profiles.google.com/stefanfussenegger

查看已验证 ID 的重定向会更有帮助，因为我总是以这个结尾:

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

好的，看来我应该关注已验证 ID 的重定向，而不是声明的 ID。

现在的问题是:遵循声明/验证 ID 的重定向是否安全，例如在像这样搜索数据库之前:

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 Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of [RFC3986] to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.

因此，根据这一点，您应该采用用户提供的标识符并按照重定向和正常的 URL 规范化程序对其进行规范化。

结果被认为是“声明的标识符”(CI)。接下来，您将进行关联舞蹈并确定此声明是否属实。

注意 - 一些提供商有一个“众所周知的”OpenId 提供商 (OP) URL，例如 Google。如果您注意到 StackOverflow 的登录过程，您只需单击 Google 按钮即可，而无需填写表格。在此变体中，“众所周知的”OP URL 不是用户 CI。用户未向您提供 CI。您需要等到您完成身份验证，Google 会告诉您用户是谁。

此时(在收到来自 OpenId 提供者的成功关联回调之后)您将拥有用户的标识符。根据 section 9.1您将收到两个 openid.claimed_id和 openid.identity ，或者如果您对扩展做一些花哨的事情，则两个字段都没有(我对规范的这方面不太熟悉)。

现在您应该存储 openid.claimed_id在您这边 - 这将是该用户唯一的标识符。这可能与用户最初提供给您的不同。它也可能与您最终到达的位置不同(在用户提供的标识符上进行重定向之后)。 OpenID 提供者拥有最终决定权。

关于对用户提供的标识符进行以下重定向的安全性。这里应该没有问题。重定向允许用户将身份验证委托(delegate)给他们选择的提供者。无论重定向将您带到何处，您最终都会要求 OpenId 提供者与您建立关联。当您提出此请求时，您将提供(标准化)声明的标识符，并且提供者可以决定他们是否希望对声明的标识符负责，并且他们将(以他们无限的智慧)授权用户拥有此声明的所有权标识符。

回到谷歌，谷歌最终会提供给你的标识符看起来和你上面的例子完全不同。他们使用的例子是 openid.claimed_id=https://www.google.com/accounts/o8/id/id=AItOawl27F2M92ry4jTdjiVx06tuFNA ( source)。

希望有帮助...