Identity 2.0、OpenID

Identity 2.0 的提法大约是 2005、2006 年间诞生的，是对一类 以用户为中心、支持跨域的身份认证机制的泛称。Identity 2.0 旨在替代现行网络系统上常用的用户名-密码验证机制，以解决用户名-密码机制的以下 缺点：

、
• 1，用户在不同网站上重复填写注册信息、记忆和管理密码的负担较重；
• 2，很多设计不周的网站使用 http 协议直接明文传输密码；
• 3，不能实现跨域的单点登录。
• 4，钓鱼网站的威胁；
• 5，键盘敲击用户名-密码有被恶意软件记录的危险；

OpenID 可能是目前 Identity 2.0 中影响力最大的一个。它最初由LiveJournal的Brad Fitzpatrick开发，后来加入了Light-Weight Identity，Yadis，Sxip DIX protocol和XRI/i-names。未来的OpenID规范正在由OpenID.net开发，很多技术公司、服务公司和开源开发者都参与其中。
OpenID 是一个 以用户为中心的数字身份认证框架，它具有 开放、分散、自由等特性。
OpenID 是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。

OpenID角色与术语：

• 终端用户(End User) — 使用OpenID作为网络通行证的互联网用户；
• 依赖方(Relying Party, RP) — OpenID支持方，支持End User用OpenID登录自己的网站；
• 身份提供者(Identity Provider, IdP, OpenID Provider, OP) — 提供OpenID URL或XRI注册和验证服务的服务提供者。
• 标识(Identifier) - 最终用户用以标识其身份的URL或XRI。

OpenID简单用户认证流程：

• 1，终端用户在OpenID Provider（OP）上面注册一个形同 URL 的 OpenID，此 OpenID 事实上仍要对应 OpenID provider 上的一组用户名-密码。
• 2,在支持 OpenID 的网站（RP）上，终端用户只需使用自己的 OpenID 登录。
• 3,该网站（RP）通过访问 OpenID URL 找到 OpenID provider，如果终端用户已成功登录OpenID provider（或在本地保存了有效的 Cookie），则 OpenID provider 向目标网站返回用户身份信息；
• 4,否则重定向到 OpenID provider 的登录界面，要求输入用户名-密码以验证用户对 OpenID 合法拥有。

OpenID详细用户认证流程（OpenID 1.0， OpenID 2.0）：

• 一个想要为其访问者提供OpenID登录网站，比如example.com，需要在页面的某个地方放置一个登录表单。与提示用户输入用户名和密码的传统登录表单不同的是，这种表单只有一个输入框：OpenID标识。网站可以选择在这个输入框旁显示一个小的OpenID图标。这个表单与OpenID客户端库的实现相连接。
• 假设用户Alice在身份提供者openid-provider.org处注册了一个OpenID标识：alice.openid-provider.org。如果Alice想使用这个标识来登录example.com，她只需要到example.com去将alice.openid-provider.org填入OpenID登录表单。
• 如果标识是一个URL，依赖方example.com做的第一件事情是将这个URL转换为典型格式，如：http://alice.openid-provider.org/。在OpenID 1.0中，依赖方接着请求该URL对应的网页，然后通过一个HTML链接tag发现提供者服务器，比如http://openid-provider.org/openid-auth.php。同时也确定是否应该使用授权身份（delegated identity）。从OpenID 2.0开始，依赖方请求的是XRDS文档（也称为Yadis文档），使用内容类型application/xrds+xml。这种类型在URL中可能存在，而在XRI中总是存在。
• 依赖方可以通过两种模式来与身份提供者通信：
checkid_immediat：两个服务器间的所有通信都在后台进行，不提示用户。
checkid_setup：用户使用访问依赖方站点的同一个浏览器窗口与身份提供者服务器交互。
• 第二种模式更加常用。而且，如果操作不能够自动进行的话，checkid_immediate模式会转换为checkid_setup模式。
• 首先，依赖方与身份提供者建立一个“共享秘密” —— 一个联系句柄，然后依赖方存储它。如果使用checkid_setup模式，依赖方将用户的网页浏览器重定向到提供者。在这个例子里，Alice的浏览器被重定向到openid-provider.org，这样Alice能够向提供者验证自己。
• 验证的方法可能不同，但典型地，OpenID提供者要求提供密码（然后可能使用cookies存储用户会话，就像很多基于密码验证的网站的做法一样）。如果Alice当前没有登录到openid-provider.org，她可能被提示输入密码，然后被问到是否信任依赖方页面 —— 如http://example.com/openid-return.php，这个页面被example.com指定为用户验证完成后返回的页面 —— 获取她的身份信息。如果她给出肯定回答，OpenID验证被认为是成功的，浏览器被重定向到被信任的返回页面。如果Alice给出否定回答，浏览器仍然会被重定向，然而，依赖方被告知它的请求被拒绝，所以example.com也依此拒绝Alice的登录。
• 但是，登录的过程还没有结束，因为在这个阶段，example.com不能够确定收到的信息是否来自于openid-provider.org。如果他们之前建立了“共享秘密”，依赖方就可以用它来验证收到的信息。这样一个依赖方被称为是stateful的，因为它存储了会话间的“共享秘密”。作为对比，stateless的验证方必须再作一次背景请求（check_authentication）来确保数据的确来自openid-provider.org。
• Alice的标识被验证之后，她被看作以alice.openid-provider.org登录到example.com。接着，这个站点可以保存这次会话，或者，如果这是她的第一次登录，提示她输入一些专门针对example.com的信息，以完成注册。

OpenID对传统用户名-密码认证机制缺点的处理：

• 缺点1：在 OpenID 中不存在，但需要权衡的是在 OpenID 中保存多少个人信息，毕竟我们对不同目标网站的信任度是不同的；
• 缺点2：OpenID provider 通过使用 https 及数字证书来解决；
• 缺点3：解决了此缺点正是 OpenID 的最大亮点。
• 缺点4：用户只要记清楚 OpenID provider 的域名，不在 OpenID provider 以外输入用户名-密码，可以在一定程度上降低钓鱼网站的威胁（但钓鱼网站仍可以伪装成目标网站来欺骗用户，获取 OpenID provider 中的非敏感信息，只是得不到密码）；
• 缺点5：OpenID 没有解决此缺点，但如果支持 OpenID 的网站多起来了，则可以大幅减少密码输入次数；

OpenID 带来的新问题是 单点失效 （分布式，故障转移）
虽然网上有很多 OpenID provider，但一个 OpenID 只保存在一个 OpenID provider 中，只要这个服务器失效了，上面所有的用户就无法登录任何基于其验证身份的网站了。解决这个问题的方法之一是使用 OpenID 的 Delegation 机制，通过另一个相对安全稳定的 URL（称为“Delegating OpenID”，位于普通的 web 服务器上即可）指向 OpenID URL。一旦原来的 OpenID provider 失效，可以在另一个 OpenID provider 上注册新用户，并将原有的 Delegating OpenID 指向新 OpenID。这时凡使用 Delegating OpenID 注册的网站账户登录不受影响。但从本质上说，保存 Delegating OpenID 的 web 服务器仍有单点失效的危险，用户最好能自己控制 Delegating OpenID 的域名，以方便在 web 服务器失效时快速迁移。但这对于大众用户来说又是不现实的。

OpenID现状：
目前 OpenID Directory 收录的支持 OpenID 登录的网站有 800 多个，其中不乏 Blogger、SourceForge 等知名网站。

• 但相当多的网站没有把 OpenID 作为自己唯一的、主推的登录方式，很多网站只使用 OpenID 的登录认证功能，而自己独立管理用户个人信息。
• 不少网站只把 OpenID 作为一个别名，绑定到已有的用户名-密码之上。
• 还有部分网站的 OpenID 用户只能使用有限的功能（例如只能给 Blog 留言，不能建立自己的 Blog），不是一个完整的账号。
• 真正把 OpenID 作为唯一入口的网站并不多，CopyTaste 是一个例子；
• Twitterfeed 以前也是，不过现在支持（并且主推的是）用户名-密码登录方式。

OpenID现状的原因分析：

• 造成这种现状很可能是因为 OpenID 的可靠性问题（单点失效）没有得到有效的解决。
• 此外，开放的 OpenID provider 市场难免鱼目混珠，也使一些网站经营者对其望而却步，毕竟网站经营者要对自己的用户数据负责。
• 抛开这些，仅仅从技术角度说，OpenID 为了开发和使用的灵活，在使用模式上没有太多的规矩，但这反而可能使开发人员对其误用，造成包括数据不一致在内的诸多问题。
• 我就在 Twitterfeed 上遇到过这样的问题（与使用 Delegating OpenID 有关），好在它的开发者 Mario Menti 热心地帮我直接修改数据库得以解决。我还因为同时使用具有相同 Email 的普通账户和 OpenID 账户，在基于 Moodle 的 Impact English 中丢失了学习记录，最终也是请教师在后台查证的。

其他Identity 2.0实现：
Identity 2.0 何时真正到来？（二）处境尴尬的 Information Card
Identity 2.0 何时真正到来？（三）生财有道的 i-name

参考：
openid 官网中文版
Identity 2.0 何时真正到来？（一）小有所成的 OpenID
OpenID&Oauth
维基百科 - OpenID