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 entirely crumble if one company turns evil or goes out of business.
An OpenID identity is just a URL. You can have multiple identities in the same way you can have multiple URLs. All OpenID does is provide a way to prove that you own a URL (identity). And it does this without passing around your password, your email address, or anything you don’t want it to. There’s no profile exchange component at all: your profiile is your identity URL, but recipients of your identity can then learn more about you from any public, semantically interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.).
Anybody can run their own site using OpenID, and anybody can be an OpenID server, and they all work with each other without having to register with or pay anybody to “get started”. An owner of a URL can pick which OpenID server to use.
While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with “AJAX”-style setups, so you can prove your identity to a site without bouncing between pages.
在这种模式下,你可以选择在任何Server上Host你的数据,甚至,你也可以自己做自己的Host Server。这样,关键问题就解决了,用户只需要选择他所信任的Server,而应用所做的,只是根据OpenID的Spec去那个Server上验证此用户的身份。
除了Livejournal,还有其它一些OpenID Host Server,比如MyOpenID.com, Videntity.org等等。不过,现在支持OpenID的应用还很少,我在想,在不久的将来,不知道OpenID能否成为Web2.0应用的通行证呢?
最后是八卦时间:
在试验我的Passport的时候,突然想起了Google Account的界面,像,说不定Google Account就是Google自己的Passport,也许哪天Google登录系统将会公开自己的SDK,不过按照Google的风格,这个API将会简单很多。Google Passport,你会相信么?
对了,还有人Hack出了自己的Google Token ("The Mysteries of X-GOOGLE-TOKEN and why it matters"。
每个应用都需要注册一个用户名和密码
每天需要输入很多次同样的认证信息
可能无法注册到自己希望的用户名
如果这些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 entirely crumble if one company turns evil or goes out of business.
An OpenID identity is just a URL. You can have multiple identities in the same way you can have multiple URLs. All OpenID does is provide a way to prove that you own a URL (identity). And it does this without passing around your password, your email address, or anything you don’t want it to. There’s no profile exchange component at all: your profiile is your identity URL, but recipients of your identity can then learn more about you from any public, semantically interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.).
Anybody can run their own site using OpenID, and anybody can be an OpenID server, and they all work with each other without having to register with or pay anybody to “get started”. An owner of a URL can pick which OpenID server to use.
While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with “AJAX”-style setups, so you can prove your identity to a site without bouncing between pages.
在这种模式下,你可以选择在任何Server上Host你的数据,甚至,你也可以自己做自己的Host Server。这样,关键问题就解决了,用户只需要选择他所信任的Server,而应用所做的,只是根据OpenID的Spec去那个Server上验证此用户的身份。
除了Livejournal,还有其它一些OpenID Host Server,比如MyOpenID.com, Videntity.org等等。不过,现在支持OpenID的应用还很少,我在想,在不久的将来,不知道OpenID能否成为Web2.0应用的通行证呢?
最后是八卦时间:
在试验我的Passport的时候,突然想起了Google Account的界面,像,说不定Google Account就是Google自己的Passport,也许哪天Google登录系统将会公开自己的SDK,不过按照Google的风格,这个API将会简单很多。Google Passport,你会相信么?
对了,还有人Hack出了自己的Google Token ("The Mysteries of X-GOOGLE-TOKEN and why it matters"。