OpenID 工作方式,以Klogs.org为例

OpenID 是一个用户中心的,以URL为身份标识的身份验证解决方案。在这个方案中,每个人可以用他/她所拥有的支持OpenID的URL,作为出入各种互联网应用/服务的钥匙。(所谓你的身份你控制)

下面,就以我自己网站的url为例,来讲讲这个OpenID的工作原理

OpenID有三种实现方式,

一种呢,使用OpenID服务商提供的URL,比如zheng.pip.verisignlabs.com;

第二种,如果自己的虚拟主机能够支持OpenID的server程序的话,不妨自己搭建;

第三种,注册的是OpenID服务商的服务,但是又想用自己Blog或者网站的url,比如我想用WWW.KLOGS.ORG,而不是verisignlabs.com的url。这种方式能够通过"委托"的方式实现。

我选择的是第三种。

首先,我已经注册了http://pip.verisignlabs.com/ 提供的OpenID服务,在那里申请的URL为:zheng.pip.verisignlabs.com

接下来,把下面两行代码插入到我的www.klogs.org首页的...中。

<link rel="openid.server" href="http://pip.verisignlabs.com/server" />

<link rel="openid.delegate" href="http://zheng.pip.verisignlabs.com" />

第一行是用来指明所采用的OpenID服务方所在的位置;第二行是说www.klogs.org实际上只是zheng.pip.verisignlabs.com的代理,真正的OpenID Url是后面这个。

这样做的好处, 有点类似于Feedsky的Feed托管,不过我的Blog,我的RSS的地址如何变幻,在Feedsky上的RSS输出并没有变化。

好了,现在我要用www.klogs.org来申请并使用其他服务了,这里选择的是OpenID的营地:OpenidEnabled.com

我在Openidenabled.com输入www.klogs.org。

提交后,作为验证需求方的Openidenabled开始工作。先是抓取我提供的URL对应页面的代码,找寻其中的OpenID申明。

在我的www.klogs.org中,Openidenabled将会发现我的OpenID的验证服务方实际上是来自pip.verisignlabs.com/server,真实地OpenID URL是 zheng.pip.verisighlabs.com,www.klogs.org只是一个被委托者。自然的,Openidenabled就要去处理zheng.pip.verisighlabs.com这个地址。

接下来,Openidenabled.com会用我的URL所声称的验证服务url生成一个公有密钥(SHARED SECRET),同时构建一个用来验证我的id的url(如下),并让浏览器转向到那里。

http://pip.verisignlabs.com/server?openid.mode=checkid_setup&openid.identity=
http%3A%2F%2Fzheng.pip.verisignlabs.com%2F&openid.trust_root=http%3A%
2F%2Fwww.openidenabled.com%2F&openid.assoc_handle=%7BHMAC-SHA1%7D
%7B44be6b1d%7D%7B3sqAgQ%3D%3D%7D&openid.return_to=http%3A%2F
%2Fwww.openidenabled.com%2Fopenid_login%3Ftoken%3DTbQQC7S86fefBIy
PEJigbtzJaYMxMTUzNDA5MzU0AHVmQk9OSGRIAGh0dHA6Ly93d3cua2xvZ3Mub
3JnLwBodHRwOi8vemhlbmcucGlwLnZlcmlzaWdubGFicy5jb20vAGh0dHA6Ly9waX
AudmVyaXNpZ25sYWJzLmNvbS9zZXJ2ZXI%253D%26came_from%3D

因为我还未登录,所以pip.verisignlabs.com提示我登录,在我成功登录之后,也就验证了我拥有我所声称的Openid url:zheng.pip.verisignlabs.com

验证的服务方此时构建一个返回到验证需求方的URL,将浏览器跳转到该页面,我就被授权能使用openidenabled.com的服务了。

表面上看,服务方跳转回来后的过程很简单,其实在后面还有更多的动作:它将检查是否有为这个验证服务方生成的公有密钥缓存。

存在缓存的话,验证服务方转过来的URL所带的Signed参数被该缓存的公有密钥验证。

不存在的话,验证需求方与验证服务方的对话还要再进行一次,服务方会返回需求方过来的签名有效。

(这里有一张Openid work flow图,表达得更清晰:)

----------

对用户来说,整个过程就是输入url,到服务端确认 ,就两个动作,一点不复杂。