OpenID协议概述1
参考内容： http://www.theserverside.com/tt/articles/article.tss?l=OpenID
OpenID 协议概述：
上图展示了 OpenID 协议中，用户， RP 与 OP 之间最常用的认证流程。分为七步
1 请求用户ID
第一步当然是要求用户提供 OpenID 了。不过这个 OpenID 也是有说法的， OpenID 可以以 URL 的形式存在，就是我们熟悉的 http 或者 https ，也可以是 XRI 的形式，不过现在为止我还没有发现 XRI 形式的 OpenID ，先放到一边不管，知道就行了。有时间看看 XRI 的语法规范 ，内容好像不是很多。
2 整理 OpenID
其实呢，用户在输入 OpenID ，点击登录之后， RP 就开始忙活了，首先就是要检查用户的 OpenID 是否符合规范，如果不符合规范，就要对 OpenID 进行修正或者补全。比如我的 OpenID 是 http://tihualong.myopenid.com 如果我输入了 tihualong.myopenid.com ，你也得认出来 ( 不然这么弱的话，谁喜欢用啊，偷懒都不能偷懒 ) 。而且更可恶的是需要考虑到 OpenID 有可能是 XRI 的形式，更增加了标准化的复杂性。该死的兼容性 ( 使用 XRI 的用户也是这么想的吧，呵呵 ) 。列一下整理的规则
1 以 xri:// xri://$ip 或者 xri://$dns 开头的，统统砍头，去掉这些标识
2 如果余下的字符串第一个字符是 xri 的全局标识符，那么它已经是规范化的 OpenID 了，否则视为 HTTP URL 进行处理，没有 http 或者 https 头的，加上 http 。
下面是一些例子：
| 用户输入的OpenID |
规范化的OpenID |
OpenID类型 |
| =example1 |
=example1 |
XRI |
| xri://$dns*example3.com |
=example2 |
XRI |
| xri://$ip*1.2.3.4 |
URL |
|
| URL |
||
| URL |
||
| example6.com |
URL |
下图是参考文章上 OpenID 的整理流程 
看起来好像也不是很复杂。不管，反正不是自己写，都有人封装好了。
3 发现阶段， RP 查询与 OP 进行通讯的方式
话说这个阶段是非常重要的， RP 使用整理过的 OpenID 查找发出请求必需的参数， RP 会瞒着用户偷偷的跟 OP 接头， RP 把自己假装成一个用户，向 OP 询问要发出一个合法请求需要提供哪些参数， OP 会返回给 RP 一个 XML 文档，告诉 RP ，我需要哪些哪些参数，这个 OpenID 的服务地址是什么什么，你要将用户重定向到哪里哪里进行登录验证等等。当然这些过程都是在用户不知道的情况下进行的。
而且，比较重要的一点是：这个阶段使用的协议以及返回的结果文档都取决于整理阶段查到的 OpenID 的标识类型
| OpenID类型 |
协议 |
结果文档 |
| XRI |
XRI |
XRDS |
| URL |
Yadis |
XRDS |
| URL |
HTML Discovery |
HTML |
4 RP 与 OP 建立关联
创建 RP 与 OP 关联之后，可以在两者之间使用加密的方式验证后续的协议消息并降低通信数 ( 不知道这样理解对不对 ) 简单来说，就是使用了一种 Diffie-Hellman 密钥交换算法生成的共享密钥对传递的消息进行数字签名。
这种机制能保证 RP 与 OP 可以进行安全的进行通信，这种安全性可以通过在传输层使用 SSL 协议或者使用 HMAC SHA1 或者 HMAC SHA256 实现。 RP 请求成功后会得到一个通讯句柄， RP 和 OP 将会在后续的活动中将它作为对消息进行加密的密钥使用。
这一步骤是可选的，因为 OpenID 协议允许不通过建立关联直接请求认证，接着请求对认证信息进行验证。这样 RP 可以是无状态的，不需要保存通讯句柄 ( 在协议中这种方法号称 dumb 模式：沉默模式 ) ，这种方式被推荐用于执行与 OP 的通信，但是如果不能用这种方式，就必须建立关联。
( 有关 openid 的加密验证模式可以参考 http://tenglong.blog.51cto.com/180708/29866)
注： OpenID 认证同时支持 “ 智能模式 ” 和 “ 沉默模式 ” 来容纳不同的 RP 。 一个智能的 RP 用保存状态信息的方式以便在开始阶段完成少许的工作。 一个 “ 沉默模式 ” 的 RP 则是完全的无状态的，但是需要一个额外的 HTTP 请求。