今天看文章讲sso，列一下我做用户中心时的一些想法。
用户中心（ucenter）与业务系统同域和业务系统是移动端的情况略过不提，列下web端跨域时的一些想法．
1、页面跳转式（标准模式）
用户进入第一次业务系统时处于未登陆状态。需要做一些登陆才能完成的操作时，业务系统引导用户跳转到ucenter提供登陆页。用户登陆完成后附带上用户code跳转回业务系统，业务系统读取用户code从ucenter获取用户token。
优点是实现简单快捷，缺点是用户进入后不能直接看到自己状态。可以靠iframe嵌入用户中心的一个特殊页面解决。
2、ucenter jsonp模式
ucenter实现一个jsonp api，调用时返回用户信息（已登陆）或提醒用户未登录。返回的用户信息可以为用户code或加密后的token。形如window.currentUserInfo={logged:success,code:"XXXX",username:"xxxxxx",avatar:"http://xxx/xxx.jpg"}或者window.currentUserInfo={logged:success,access:已加密的({access_token:xxxxxx,refresh_token:yyyyyyyy}) ,username:"xxxxxx",avatar:"http://xxx/xxx.jpg"}
业务系统页面上加一段代码，判断用户是否已登陆，若未登陆则以添加script的形式嵌入这个api。后续嵌入js读取信息，按业务需求返回给业务后台读取用户信息。
3、业务系统jsonp模式
业务系统实现一个jsonp api (形如http://a.com/jsonp.php)，将其注册到ucenter。 ucenter实现一个302跳转 api，调用时读取referer信息判读来自哪个业务信息，然后将用户code作为参数附加到业务系统预先定义的api url后面（形如http://a.com/jsonp.php?code=xxxxx）。
业务系统页面上加一段代码，判断用户是否已登陆，若未登陆则以添加script的形式嵌入这个ucenter的302 api。业务系统后台读取到用户code后从ucenter得到用户信息，按业务需求返回合适信息给前台。
与前一个模式相比，优点是返回的数据结构由业务系统控制，更易于后续操作。
4、设置Access-Control-Allow-Origin
业务系统直接读取ucenter关于用户信息的api，优点是实现最简单。