共享Session实现单点登录这种方式的缺点是什么？

Question

问题如题。另附我的疑虑：

1. 如果验证token的工作全部交给“SSO服务”来完成，这样“SSO服务”的压力不是会很大吗？CAS方案或SAML协议验证token的工作都是交给"SSO服务"的。假定谷歌的id.google.com是他的“SSO服务”，其它业务服务，如:mail.google.com、www.google.com、blog.google.com等平均并发请求为:1k req/s， 那么id.google.com是不是要承受3k req/s的请求量？当然，假设每一个请求都需要用户处于登录状态。

2. 如果把token缓存在“业务服务”上，让各个“业务服务”也能验证token，这样“SSO服务”的压力就会大大降低。是不是这么干的？

3. 缓存token的方式跟共享Session的方式有异曲同工的意思，改个名字共享Token。我如果用redis集群的方式来共享token，让id.google.com写token，其余的业务服务读token。这样做好吗？

最近在写SSO的系列博客，上面的疑虑一直让我很纠结。劳烦有这方面业界开发经验的前辈指点下。

---

补充：问过同学，他说现在尽量让web服务变得无状态化，session机制是处在web服务下的状态机制，会增加web服务的负担。可能是这样，一个佐证就是：node.js的express4开始默认不使用session。虽然真正的问题依然没有解决，可能太过于细节来吧，但还是很感谢大家的回答！

Answer 1

我觉得只是第一次同步吧，我之前做的是，首先在用户登录的时候直接同步用户资料了，不用每次都同步这样很慢，同步用户后就跟SSO没关系了，都是本地操作的，更改用户资料就跳转到SSo

Answer 2

同步站点过多 造成登陆缓慢

Answer 3

@xingfeilong 呃。。。还是有点不太理解。同步的方式是redis的读写分离，这样也会慢吗？