前几天看到 Twitter 上关于我的 blog 新文章的提醒似乎有点问题，于是就去 TwitterFeed 上去检查设置，结果登陆的时候让我困惑了好久——我到底是改用普通登陆呢，还是用 OpenID？
我在注册 TwitterFeed 的时候，应该算是处于对于 OpenID 迷信的时期，因此那段时间里注册的帐号，只要支持 OpenID 我都用 OpenID 来注册。OpenID 支持用自己的域名来做帐号，方法是在域名的 index.html 文件的 <head> 部分添加几行代码就行了。不过，这只是一个代号，真正认证时其实还是要到 OpenID 的服务器上进行的。我当时知道了这个功能之后，也没有多想，于是就在所有注册的时候尽可能的用了 OpenID 的技术。
其实，OpenID 技术从根本上说是否优秀，我们还没有结论。但 OpenID 本身最大的问题，现在看来在于推广。如果全球网站有 50％ 能用上 OpenID 技术，那么 OpenID 的推广在我看来就是成功的；成功就意味着有了前景、有了未来。但让一个网站使用 OpenID 虽然并不是太过困难的事，但也不是选中一个选项就能搞定的。因此，OpenID 的推广还远远没有达到目标。而这种技术，一旦没有在第一波流行起来，再往后就没有后劲了。看看今天，有多少网站还不遗余力的支持 OpenID 啊？就算事支持，也不过事系统本身有这么个功能，不用白不用，所以就开启了这项功能，但 OpenID 绝对不是这种网站的主要推荐的登陆方式。
在个人用户方面，OpenID 确实是给我带来了一些小麻烦。比如用自己的域名来做 OpenID 这件事，我自己的网页在更换了几次服务器后，内容早就和最开始时不一样了。开始时我想把首页做成一个门户，于是就用了 HTML 简单写写；后来我想用 CMS 系统来把首页一起自动化统一管理了，中间尝试过 Movable Type、UseMod Wiki 之类的系统；到了最后我把首页重定向到我的 wiki 中的用户页面。在这个过程中，首页中的那几行关于 OpenID 的代码早就不知道扔到哪里了。
这样的后果是，OpenID 网站在登陆的时候只认我的域名，连我原本在 OpenID 服务网站上的帐号都不认；但我的首页里的 OpenID 代码没了，因此输入我的域名后又无法完成认证，这真是一个死循环啊。我忘了那次我是怎么解决问题的了，要么我去 OpenID 网站上找要插入首页的代码，要么我就放弃登陆那个网站。不惯我当时是怎么做的，我那时后悔的心情确实肯定的。
随着 Google 等一些公司把自己的帐号系统开放，让其它网站可以与之关联，我觉得这个行为直接宣判了传统 OpenID 的死刑。其实，Google Profile、Facebook 帐号、Twitter 帐号登陆这些功能，从本质上来说，就是 OpenID。但它们把传统的 OpenID 概念改头换面，用自己网站的帐号给重新包装了一下而已。试想，当我的 Google 邮箱的帐号可以用来登陆一个网站的时候，我干嘛还要去回忆我不知道多少年前的 OpenID 帐号呢？说起帐号本身，Google Profile 有邮箱、文档等功能，Facebook 和 Twitter 各自有各自的 SNS 功能，而 OpenID 的帐号，只有单一的一个“登陆”功能，简直是太可怜了。
还记得用 OpenID 来注册一个网站么？在注册之后网站其实也会问你要私人信息，其中就包括了你的电子邮箱。每次到这一步的时候，我都有种多此一举的感觉。既然已经有了我的电子邮件，那么再输入一个密码不就相当于重新申请了一个帐号了么。因此，OpenID 在这里，我觉得优势不大。至于可以统一管理密码的问题，在密码软件推出之后，就更不是问题了。所以相比起来，让 Google 这些有其它服务的帐号来顺便管理第三方网站的登陆就比较自然了，而为此专门弄一个 OpenID 的服务来就有些多此一举了呢。
OpenID 最后一个让我担心的问题就是它的有效性。OpenID 的帐号是建立在一个网站上的，一旦这个网站倒了，那么我们之前用这个 OpenID 注册的网站不都登陆不上去了么？在这方面，还是 Google、Facebook 这些大公司更让人放心一些。而用电子邮箱来登陆的，有 Google Apps 加上个人的域名就更不用担心了，因为认证都是在各自网站上的，因此不会受别的网站的影响。如果有一天 Google 倒了，Google Apps 不存在了，因为域名还是自己的，那么电子邮箱就永远都是自己的了，完全不用担心有效性的问题。