请教单点登录设计

1:系统情况:
业务:公司做b2b平台,下面有供应,独立分销系统(自己域名)、采购用户类型。独立分销用的是一套系统(包括用户数据),但是它有自己独立的域名,看成不同的网站。另外还有几个相关的业务系统(与b2b平台不同的域名)。
物理:分南方、北方两个机房;有专线同步业务数据。
2:单点登录需求
系统之间登录一次,可以访问其他系统。中心网站(单点登录服务器)故障,先保证业务系统可以登录。
3:考虑的方案
a:通过登录后在中心网站创建token,然后将Token返回到应用系统A,在需要单点跳转的地方,将token带到url上,通过该url跳转B。跳转到B业务系统后,再根据token到中心网站验证,通过后即为登录。
缺点:url一直有效,在网吧或者局域网上容易被拦截。
b:做成京东,淘宝类似的。当第一次登录成功后,再异步通过 jsonp方式,跨域设置相关业务站点(顶级域名)的凭证信息保存在Cookie中,子域共享该Cookie。跳转的时候,通过浏览器自动获取到Cookie。
缺点:公司的顶级域名比较多(属于公司的有3-4个),还有上百的独立分销域名。跨域请求上百的顶级域名本身就不太合理。Cookie方式还有XSS和CSRF方面的安全性。

限于能力,个人对单点登录涉入不深。不知道各位有没有什么好的建议或者较为成熟的方案。请指教!

To banq:
阅读了推荐的文章,目前还有些疑问:
1:基于Token的机制,Token在哪里生成?在应用服务端或是单点服务端?
2:从一个系统跳转到另一个系统,Token是怎么处理的呢?
文章提到设置http header。
当用a标签,从系统1跳转到2呢?

>目前还有些疑问

可看看OAuth

==本地登录模式==
1.在本地登陆,并生成token
2.用JSONP+P3P HEADER将本地token传递到中心服务器
3.中心服务器根据信任站点和分站用户对应关系决定是否要创建中心token
4.中心token写入cookie
==中心登陆模式==
5.在本地验证中心toke并登陆

token,如果存在跳转,那么就用auth_code代替,用auth_code在获取token。

如果不存在跳转,那就没关系。

你要说拦截,用cookie一样会拦截,有啥差别?

token和cookie的区别,一个在header里,一个在url上..