编辑:我上面描述的是标识符选择机制。虽然 directed identity 需要 identifier select,并且有时确实用于指代 identifier select,但这两个术语是不同的。见this article。无法检测定向身份。
定向标识符是一个不透明的标识符,对于给定的站点是唯一的。相同的 OpenID URL 不断地返回给给定的消费站点,但从来没有两个消费站点为用户提供相同的 OpenID URL。定向身份可防止串通。
原创
我不明白您为什么在 OpenID 规范中链接到“5.1. 直接通信”。据我了解,“定向身份”是指 OpenID 提供者通过选择可用于标识自己的标识符引导用户(参见“定向身份”下的here)。
例如,为了识别您的 google 帐户,您不会直接向中继方提供您声称拥有的标识符(尽管您可以),而是提供
https://www.google.com/accounts/o8/id
然后 Google 会生成一个特定于 OP 的匿名标识符,例如
www.google.com/accounts/o8/id?id=aitodwer
这是实际声明的标识符。
OpenID 提供者不“要求”定向身份,但它可能不支持它。决定是否使用定向标识的是用户是输入他声称拥有的标识符还是输入提供者 URL。尽管提供者可能不支持定向身份,但它始终支持非定向类型,即使在 Google 的情况下,您无法先验地知道您声明的标识符将是什么(Google 会为每个中继方生成一个)。这是因为中继方必须能够对声明的标识符执行发现(如果中继方是无状态的,则可能执行直接验证)。 (嗯,从技术上讲,提供者可能会在没有 identifier_select 的情况下禁止身份验证请求,但我认为没有人会这样做)
您可以轻松检测到这种情况正在发生。用户向中继方输入“用户提供的标识符”。在对该标识符执行发现后,中继方将either have:
- 仅提供者端点 URL 和协议版本(“定向身份”)。在这种情况下,中继方将使用特殊值
http://specs.openid.net/auth/2.0/identifier_select 作为声明和 OP 本地标识符。
- 提供者端点 URL、协议版本、声明的标识符(用户提供的标识符)和 OP-local 标识符(OP-local 标识符是特定于某个端点的标识符 - 例如,我可以设置向上 www.mydomain.com 以发现多个 OpenID 提供者,每个提供者都有不同的 OP-local 标识符)
以下是两种情况下 XML 的外观:
定向身份(来自 Google 的示例 - 请注意不存在 LocalId 元素)
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://openid.net/srv/ax/1.0</Type>
<Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
<Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>
<Type>http://specs.openid.net/extensions/pape/1.0</Type>
<URI>https://www.google.com/accounts/o8/ud</URI>
</Service>
</XRD>
</xrds:XRDS>
非定向身份(来自规范的示例)
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<URI>https://www.exampleprovider.com/endpoint/</URI>
<LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>
请注意,定向身份的缺点是中继方必须验证断言中声明的标识符,因此需要再进行一次发现(请参阅here)。