我目前正在为网站实施 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 做了一些专门的巫术来把事情弄清楚。
查看OpenID 身份验证规范的 7.2 规范化,我发现:
然后,URL 标识符必须在检索其内容时通过以下重定向进一步规范化,最后将 [RFC3986] 第 6 节中的规则应用于最终目标 URL。依赖方必须将这个最终 URL 记录为声明的标识符,并在请求身份验证时使用。
对声明的 ID 进行重定向并没有太大帮助,因为我仍然有两个不同的 ID:
查看已验证 ID 的重定向会更有帮助,因为我总是以这个结尾:
好的,看来我应该关注已验证 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 时也应该这样做,对吧?
(如果我真的应该遵循重定向,我还有一个关于潜在恶意重定向的问题,但这必须等到我得到这个问题的答案。无论如何可能已经过时了)