Identity 2.0 何时真正到来？（一）小有所成的 OpenID
最近做了一些和用户管理系统相关的调研，了解到“Identity 2.0”这个概念。Identity 2.0 的提法大约是 2005、2006 年间诞生的，是对一类以用户为中心、支持跨域的身份认证机制的泛称。Identity 2.0 旨在替代现行网络系统上常用的用户名-密码验证机制，以解决用户名-密码机制的以下缺点：
1. 键盘敲击用户名-密码有被恶意软件记录的危险；
2. 很多设计不周的网站使用 http 协议直接明文传输密码；
3. 钓鱼网站的威胁；
4. 用户在不同网站上重复填写注册信息、记忆和管理密码的负担较重；
5. 不能实现跨域的单点登录。
OpenID 可能是目前 Identity 2.0 中影响力最大的一个，我也算是在 OpenID 刚推出之后就使用的用户。它最初是由 LiveJournal 等公司发起的开放技术，允许任何人建立用户管理和认证节点（OpenID provider），用户可以在上面注册一个形同 URL 的 OpenID，此 OpenID 事实上仍要对应 OpenID provider 上的一组用户名-密码。在支持 OpenID 的网站上，用户只需使用自己的 OpenID 登录。该网站通过访问 OpenID URL 找到 OpenID provider，如果用户已成功登录 OpenID provider（或在本地保存了有效的 Cookie），则 OpenID provider 向目标网站返回用户身份信息；否则重定向到 OpenID provider 的登录界面，要求输入用户名-密码以验证用户对 OpenID 合法拥有。OpenID 没有解决上述缺点1，但如果支持 OpenID 的网站多起来了，则可以大幅减少密码输入次数；OpenID provider 通过使用 https 及密码摘要可以解决缺点2；用户只要记清楚 OpenID provider 的域名，不在 OpenID provider 以外输入用户名-密码，可以在一定程度上降低钓鱼网站（缺点3）的威胁（但钓鱼网站仍可以伪装成目标网站来欺骗用户，获取 OpenID provider 中的非敏感信息，只是得不到密码）；缺点4在 OpenID 中不存在，但需要权衡的是在 OpenID 中保存多少个人信息，毕竟我们对不同目标网站的信任度是不同的；而解决了缺点5正是 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 Directory 收录的支持 OpenID 登录的网站有 800 多个，其中不乏 Blogger、SourceForge 等知名网站。但相当多的网站没有把 OpenID 作为自己唯一的、主推的登录方式，很多网站只使用 OpenID 的登录认证功能，而自己独立管理用户个人信息。不少网站只把 OpenID 作为一个别名，绑定到已有的用户名-密码之上。还有部分网站的 OpenID 用户只能使用有限的功能（例如只能给 Blog 留言，不能建立自己的 Blog），不是一个完整的账号。真正把 OpenID 作为唯一入口的网站并不多，CopyTaste 是一个例子；Twitterfeed 以前也是，不过现在支持（并且主推的是）用户名-密码登录方式。造成这种现状很可能是因为 OpenID 的可靠性问题（单点失效）没有得到有效的解决。此外，开放的 OpenID provider 市场难免鱼目混珠，也使一些网站经营者对其望而却步，毕竟网站经营者要对自己的用户数据负责。抛开这些，仅仅从技术角度说，OpenID 为了开发和使用的灵活，在使用模式上没有太多的规矩，但这反而可能使开发人员对其误用，造成包括数据不一致在内的诸多问题。我就在 Twitterfeed 上遇到过这样的问题（与使用 Delegating OpenID 有关），好在它的开发者 Mario Menti 热心地帮我直接修改数据库得以解决。我还因为同时使用具有相同 Email 的普通账户和 OpenID 账户，在基于 Moodle 的 Impact English 中丢失了学习记录，最终也是请教师在后台查证的。
对传统 OpenID 的安全性进行小幅改进的是 VeriSign Labs 推出的 Personal Identity Portal (PIP)，它可以使用数字证书、电子口令牌或手机动态口令等方式对 OpenID 的登录进行二次验证。这使得 OpenID 的密码即使被他人窃取，也无法在别的电脑上轻易登录。除安全型 OpenID 之外，PIP 还提供密码托管服务，将其它网站的密码保存在 PIP 上，用户只要成功登录了 PIP 就可以免输密码直接登录那些网站。这种服务严格地说不算是 Identity 2.0，但确实不失为一种不用修改目标网站（或只要求其增加少量安全的 REST API）即可实现跨域单点登录的模型。密码托管可以防止钓鱼和键盘记录，并尽可能地帮用户选择 https 登录通道。国内也有像豌豆网、PassBox 这样的密码托管服务提供商，然而这种使用模式的缺点显而易见：任凭服务商宣称其技术和管理上如何安全，也难以说服用户放心地把密码保存在第三方的服务器。有恶意的服务商完全有能力借此窃取用户的密码，这时服务商本身变成了一个钓鱼网站。此外值得一提的、和 Identity 2.0 关系不大但有可能成为另外一条思路的是同 PIP 紧密结合的 VeriSign Identity Protection (VIP) 服务，用户可以申请电子口令牌（收费）或安装手机动态口令软件（免费），作为登录支持 VIP 的网站的二次验证凭据，这很像国内一些银行所采用的动态口令牌。VIP 和 OpenID 一样，也需要目标网站的支持，目前支持它的多为美国的消费类网站，其中 PayPal、eBay 等对中国用户可能也有实用意义。如果 VeriSign 能将 PIP 和 VIP 开放标准，或许可以推动 OpenID 标准的进步和市场的开拓。
同样基于 URL 的身份认证机制还有 LID (Light-Weight Identity)。OpenID 和 LID 的发起者很早便意识到不同机制间互操作的重要性，因此他们共同制定了 Yadis 服务发现协议，使得二者在一定程度支持互操作。目前 LID 的影响力不如 OpenID，MyLID 可能是唯一一家正式运营的 LID provider。当然 LID 也是开源的，允许任何人建立自己的 provider。
和 OpenID 机制类似的是微软的 Windows Live ID，也就是通常所说的 Hotmail 或 MSN 账号。除了是由微软独家提供身份认证服务器并使用 Email 作为用户名称，其工作原理和特性与 OpenID 大同小异。尽管微软提供了比 OpenID 更加易用的 SDK，但是 Windows Live ID 目前只在微软的各种网站，如 Imagine Cup、微软学生中心上普遍使用，第三方网站使用得很少，也许是对微软这个巨头及其垄断的标准怀有戒心。一家 OpenID provider 倒了可以换另一家，但如果微软对 Windows Live ID 撒手，使用它的第三方网站和用户都会遭殃。此外，反对者还认为使用 Email 作为用户名称更容易招致垃圾邮件。
4条评论 关于 “Identity 2.0 何时真正到来？（一）小有所成的 OpenID”
由 paul 发表于2009-08-14
我最近刚好在考虑一种松散的域间认证机制。这种机制中关注的核心信息是”User u is valid @ Domain da"。
所有参与此机制的域独立维护自己的用户系统，用户可以使用u@da尝试登录任何一个域dn（不需要密码），则dn将redirect到已在dn注册的da的登录点，由da对用户进行常规的验证（cookie|password），之后带着ticket返回dn，dn再用一个https webservice获得用户在da的基本信息。这种过程本身是很常见的，貌似就是在Google API上学到的。
此时dn只是确认当前用户是da上的u，至于dn对da上的u提供怎样的服务，取决于dn的策略。不在此机制内（如若便于推广，也应提供一些常见的策略的建议以及在常见系统forums/wp等的实现）。
提供认证的Provider Domain和接受认证信息的Customer Domain是这种机制中的两种基本角色。所谓松散，就是任何两个以上站点都可以使用这种机制建立互相接受认证的机制。
此外，为了进一步增强通用性，可以设立公益的Provider Discovery Server。当u@da尝试登录dn，而dn上并没有da登录接口的注册时，dn可向pds请求da，如da已在pds注册，而dn设置为接受来自pds的注册时，dn可使用pds返回的信息完成da的注册，进而完成u@da的登录过程。这种过程虽然形成了对单点pds的依赖，但是只在da在dn上注册时发生一次（或在之前的注册失效后），而在用户登录过程中并不发生；当然这种注册过程也可以手动完成。（在标准形成后，可约定一个webservice获取provider的必要信息。只需在dn上指定这个discovery webservice即可）。
在这种机制中，参与各方da/dn对认证开关都是可控的;用户信息也是安全的，也没有对单点的过分依赖。参与各方基本对等。从成本/受益上说，da虽然为dn提供验证，但验证的都是da的用户，dn虽然接受的da的用户，但也扩大了自己的用户范围。
目前这个想法还不很成熟，但是一个美好愿景就是你可以用linjian@linjian.org登录所有的站点，而我也可以在任何站点使用paul@wangxiaoxing.net这个唯一的身份。
尚有很多细节不及赘述，我将尝试写一份文档来详细阐述。林兄见多识广，我有一个问题是，这种机制在以前或者现在是否已经有（类似的）实现？
由 Jian Lin 发表于2009-08-15
@paul 我基本看明白了你的意思。我觉得做身份认证机制，首先需要回答的一个问题是：这是面向终端用户的认证机制，还是面向软件、系统内部使用的认证机制。从你的描述看，你想做的应该是面向终端用户的认证机制。对于这类机制，我觉得“最小吃惊原则”是很重要的：要让用户容易理解，一看就会；基于现有的 Web 机制，不在客户端部署额外的组件等等。OpenID 和 Information Card 的解决方案你应该清楚，我感兴趣的是你如何解决这些问题（或者你不认同我这些原则，可以说说你的原则）。
在面向软件、系统内部使用的认证机制中，Globus 的访问控制机制不知你有没有看过，它是一套基于代理证书的，可以实现单点登录、跨管理域用户认证和资源授权的安全框架。这套思路也许可以借鉴。但它的复杂度也可想而知（涵盖认证、管理、授权、证书、安全性），我觉得首先还是要确定自己的目标（比如只做认证一块并保证安全），然后“K.I.S.S.”为好。
由 詹小兵 发表于2009-08-19
你的想法代表了大部分电脑用户最头疼的事情，就是不听的去使用不同的注册信息去不停的登陆不同的认证界面，繁琐无趣而且时间速度都消耗不少，，。。我有个好建议，为什么不把电脑登陆边的更贴近用户自己性格习惯做法的更独立的识别认证系统，智能加锁保护用户权益，也最好是独立组件去管理控制哦，同时也可以消除卸载，。。