OpenID协议概述1

tihualong

浏览: 27194 次
性别:
来自: 北京

最近访客更多访客>>

ko889910

石開猶

zwwko

wy254527573

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

OpenID

XML 算法 HTML 活动 Blog

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	http://example3.com	URL
http://example4.com/	http://example4.com/	URL
https://example5.com/	https://example5.com/	URL
example6.com	http://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 请求。

查看图片附件

分享到：

OpenID协议概述2 | 体验OpenID

2008-12-31 22:43
浏览 4959
评论(4)
查看更多

4 楼 tihualong 2009-05-15

eyesmore 写道

RP 使用整理过的 OpenID 查找发出请求必需的参数， RP 会瞒着用户偷偷的跟 OP 接头， RP 把自己假装成一个用户，向 OP 询问要发出一个合法请求需要提供哪些参数， OP 会返回给 RP 一个 XML 文档。Discovery阶段，RP应该只是向用户声称的openid发送请求，如果使用代理的话，接收该请求的不一定是OP，比如有的人用自己的私人站点作为openid，但是他并不是openid provider，而只是openid provider的一个代理。  另外，Discovery阶段返回的也不一定是xml文档，可能是HTML的。但如果是HTML的，对<head></head>中的一些标签有要求。

谢谢，你是对的，关于代理openid这一部分我不太清楚，搞错了。

3 楼 eyesmore 2009-05-14

RP 使用整理过的 OpenID 查找发出请求必需的参数， RP 会瞒着用户偷偷的跟 OP 接头， RP 把自己假装成一个用户，向 OP 询问要发出一个合法请求需要提供哪些参数， OP 会返回给 RP 一个 XML 文档。

Discovery阶段，RP应该只是向用户声称的openid发送请求，如果使用代理的话，接收该请求的不一定是OP，比如有的人用自己的私人站点作为openid，但是他并不是openid provider，而只是openid provider的一个代理。另外，Discovery阶段返回的也不一定是xml文档，可能是HTML的。但如果是HTML的，对<head></head>中的一些标签有要求。

2 楼 tihualong 2009-04-15

siriuscor 写道

引用这样 RP 可以是无状态的，不需要保存通讯句柄 ( 在协议中这种方法号称 dumb 模式：沉默模式 ) ，这种方式被推荐用于执行与 OP 的通信，但是如果不能用这种方式，就必须建立关联。It is RECOMMENDED that a Relying Party form associations if it is possible for it to do so. If a Relying Party is incapable of creating or storing associations, Section 11.4.2 (Verifying Directly with the OpenID Provider)  provides an alternate verification mechanism referred to as Stateless Mode. 应该是建立关联是推荐方式,无状态模式是在RP无法保存关联时候使用

谢谢你的提醒，确实是我弄错了，唉，E文不好就是受影响啊

1 楼 siriuscor 2009-04-14

引用

这样 RP 可以是无状态的，不需要保存通讯句柄 ( 在协议中这种方法号称 dumb 模式：沉默模式 ) ，这种方式被推荐用于执行与 OP 的通信，但是如果不能用这种方式，就必须建立关联。

It is RECOMMENDED that a Relying Party form associations if it is possible for it to do so. If a Relying Party is incapable of creating or storing associations, Section 11.4.2 (Verifying Directly with the OpenID Provider) provides an alternate verification mechanism referred to as Stateless Mode.

应该是建立关联是推荐方式,无状态模式是在RP无法保存关联时候使用

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论