dumb mode流程

1、提示end user输入OpenID identity，identity是一个URI，比如http://carol.example.com/Alice
2、官方文档叫（Relying Party），也就是我们的服务提供方，对用户的OpenID identity URL进行标准化，然后通过http GET方法请求该URL，返回含如下header的html页面
<link rel="openid.server" href="/http://carol.example.com/openidserver.cgi">
3、重定向end user的浏览器到openid.server（上一步获取到的server url），含如下的参数
openid.mode = checkid_setup
一种验证用户id的模式，先让openid server获取用户浏览器的控制权，完成验证后，然后再通过openid.return_to参数指定的值将控制权重定向给Relying Party。
openid.identity = http://carol.example.com/Alice
end user 提供的OpenID identity
openid.return_to = http://bob.example.com/comment.cgi?session_id=Alice&nonce=123456
当完成认证后希望openid server将用户浏览器重定向的地址，当然openid server会附上一些额外的参数来验证end user 就是OpenID identity标识的那个人。nonce一个随机值，让这个重定向url唯一，不易被伪造。

4、openid.server验证用户的真实性，openid协议不关心认证的过程，所以openid.server可以自由发挥，无论是比对用户名和密码也好，使用指纹识别也罢，使用视网膜识别也行，
5、完成认证后，openid.server将end user的浏览器重定向到第三步提供的openid.return_to，并附上如下的值：
openid.mode = id_res
"id_res"表示end user就是OpenID identity所声明的那个人，可选的值还有"cancel",表示用户取消了认证
openid.return_to = http://bob.example.com/comment.cgi?session_id=Alice&nonce=123456
第三步的openid.return_to
openid.identity = http://carol.example.com/Alice
第三步的openid.identity
- openid.signed = mode,identity,return_to
表示mode,identity, return_to参数是通过摘要(signature)保护的。
- openid.assoc_handle = *opaque handle*
签名使用的key的句柄
- openid.sig = *base 64 encoded HMAC signature*
摘要的值
6、Relying Party向openId.server地址http://carol.example.com/openidserver.cgi发起一个POST请求，附上如下的参数
- openid.mode = check_authentication
表示请求的目的是确认第5步的结果是openId.server发布的，也就是end user是OpenID identity所标识的。
- openid.signed = mode,identity,return_to
第五步中的openid.signed参数
openid.assoc_handle = *opaque handle*
第五步中的openid.assoc_handle
- openid.sig = *base 64 encoded HMAC signature*
第五步中的openid.sig
- openid.* = everything else
除mode参数外，签名保护的参数【dentity,return_to】都需要在响应中回传。
7、openId.server使用openid.assoc_handle查找到对应的key,然后对第6步中openid.signed参数标识的参数进行计算签名，然后和openid.sig进行比较，如果相等那么验证正确，否则验证失败。

openid.mode = checkid_immediate
在第三步中我们使用的是openid.mode = checkid_setup，这会导致先重定向到openid.server,然后openid.server将浏览器重定向到Relying Party，使用checkid_immediate模式，就没有重定向发生了，如果验证成功，浏览器就可以直接发送一个openid.mode = check_authentication请求，如果失败，返回openid.user_setup_url，然后去这个地址(比如在一个小的弹窗中处理)验证用户信息。

smart mode

Relying Party事先获取openid.server的key,就是openid.assoc_handle所标识的key,这样，第5步后，Relying Party自己校验验证的结果，这样可以省略掉第6步，减少网络带宽和openid.server的负载。具体步骤
1、Relying Party 请求http://carol.example.com/openidserver.cgi,并带上如下参数：
openid.mode = associate
表示Relying Party和openid server要建立共享key关联
?openid.assoc_type = HMAC-SHA1
key的类型，当前只支持HMAC-SHA1
openid.session_type = *blank*
session 类型，如果为空，表示使用裸文本，DH-SHA1表示使用Diffie-Hellman秘钥交换系统
openid.dh_* = *meh*
使用Diffie-Hellman key交换策略时相关的其他参数

参考文献

http://wiki.openid.net/w/page/12995171/Introduction?mode=embedded

Posted in: MySQL practise