2

我正在尝试扩展LightOpenID PHP 库以“发现”身份提供者需要定向身份。这应该很容易，因为该库编写精美且非常干净，但我不知道如何识别这些类型的提供程序。我尝试过的几件事：

  • 我查看了有关该主题的OpenID 规范，但空手而归。
  • 浏览了PHP OpenID库，但无法弄清楚在发现过程中如何收集这些信息。
  • 通过在 LightOpenID 中注入一些代码，转储了来自服务器的所有数据（标题和内容），但没有看到任何有用的信息。
  • 自然而然地搜索了 Google 和 Stackoverflow。

提供商如何将自己标识为需要“定向身份”身份验证？肯定有一个仔细定义的规范……某处。

有谁知道我在哪里可以找到更多关于这方面的信息？

4

1 回答 1

5

编辑：我上面描述的是标识符选择机制。虽然定向身份需要标识符 select，并且有时确实用于指代标识符 select，但这两个术语是不同的。见这篇文章。无法检测定向身份。

定向标识符是对给定站点唯一的不透明标识符。相同的 OpenID URL 不断地返回给给定的消费站点，但从来没有两个消费站点为用户提供相同的 OpenID URL。定向身份可以防止串通。

原来的

我不明白你为什么链接到 OpenID 规范中的“5.1. Direct Communication”。据我了解，“定向身份”是指 OpenID 提供者通过选择可用于标识自己的标识符来引导用户（请参阅此处的“定向身份”下）。

例如，要识别您的 google 帐户，您不会直接向中继方提供您声称拥有的标识符（尽管您可以），而是提供

https://www.google.com/accounts/o8/id

and then Google generates an anonymous identifier specific to the OP, like

www.google.com/accounts/o8/id?id=aitodwer

which is the actual claimed identifier.

The OpenID provider does not "require" directed identity, but it may not support it. What determines whether directed identify will be used or not is whether the user enters an identifier he claims he owns or enters a provider URL. Although the provider may not support directed identity, it always supports the non-directed kind, even if, as in the case of Google, you cannot know a priori what your claimed identifier will be (Google generates one per Relaying Party). This is because the Relaying Party must be able to perform discovery on the claimed identifier (and maybe perform direct verification if the relaying party is stateless). (well, it's technically possible the provider would forbid authentication requests without identifier_select, but I don't think any does that)

You can easily detect this is happening. The user enters the "user supplied identifier" to the relaying party. After it performs discovery on that identifier, the relaying party will either have:

  • The provider endpoint URL and protocol version only ("Directed Identity"). In this case, the relaying party will use the special value http://specs.openid.net/auth/2.0/identifier_select as both the claimed and the OP-local identifier.
  • The provider endpoint URL, the protocol version, the claimed identifier (the identifier the user supplied) and the OP-local identifier (the OP-local identifier is an identifier that's specific to a certain endpoint – for instance, I could set up www.mydomain.com to result in the discovery of several OpenID providers, each one with a different OP-local identifier)

Here's how the XML will look in both cases:

Directed identity (example from Google – note the inexistence of an LocalId element)

<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>

Non-directed identity (example from the spec)

<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>

Note that directed identity has the disadvantage that the Relaying Party must verify the claimed identifier in the assertion, making necessary one more discovery (see here).

于 2010-06-13T08:50:05.540 回答