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参数被该缓存的公有密钥验证。

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