Posted in 互联网, 技术 at February 20th, 2006
| 14 Comments »
Web2.0的应用越来越多,对SSO的需求也就愈发强烈,Delicious,Flickr,Mail,Blog,43things, Feedburner……,每个应用都有自己的一套Identit需要维护,这带来了很多问题,比如:
每个应用都需要注册一个用户名和密码
每天需要输入很多次同样的认证信息
可能无法注册到自己希望的用户名
如果这些Web2.0应用能够采用某种Single Sign-On系统,会带来很多好处:
简化Web2.0的开发,不需要开发Identity认证,只需要集成SSO的SDK
用户只需要记住一个简单的Identity就可以
统一认证,方便集成各种Web2.0的应用
BTW:这里需要分清Authentication与Authorization的区别:SSO负责的仅仅是Authentication - is proving that You Are Who You Say You Are,Authorization则是某个Identity在这个应用系统中有什么数据,这是Web2.0网站自己的事儿。
最先想到的是Microsoft Passport,它的基本工作原理是:
1) 客户端对Passport合作站点(比如MSN Space)发出访问请求,检查Cookie是否有Passport登陆验证的Cookie,如果没有,则显示"登陆"按钮;
2) 点击登陆按钮,Redirect -> Passport.com 进行验证,参数:
returnUrl - 返回到应用的URL
SiteID - 合作站点的ID
3) Passport检查客户端Cookie,如果用户未登陆(用户有可能在其它的Passport-Enable站点登陆过),则显示登陆页面;如果登陆过,则更新Cookie,到(5);
4) 用户提交登陆数据(用户名、密码,有时还图像验证等),HTTPS发送;
5) Passport验证用户身份,生成sid,重定向回刚才传递的那个returnUrl,也就是Passport的应用站点。
6) Passport合作站点通过预先约定验证SID,并生成本地Cookie,显示"登出"按钮。
其实,类似的SSO方案还有很多,有跨网站应用的,比如Sixapart的Typekey;也有本公司的Passport,比如Sohu Passport(Sohu Passport的认证页面是通过HTTP明文传的…),还有为了其它应用集成的,比如Flickr API中的认证。
这种SSO解决方案中最重要的三个元素为:
SiteID - 标识哪个合作应用站点
ReturnURL - 要返回的页面
SID - 预先约定的某种认证方式。比如对称密钥加密,或者PKI公钥技术
这种解决方案,所有的用户隐私资料都是保存在中心服务器中的。这就带来了一个问题,由谁来替大家Host用户的隐私数据呢?如果是某个中心化的Server,谁能相信这个Server呢?
Livejournal的创始人给出了他的答案 - OpenID。
This is a decentralized identity system, but one that’s actually decentralized and doesn’t […]
Popularity: 66%