单点登录——实现原理

       单点登录，Single  Sign  On，也就是我们平时所说的SSO。一般大型的系统平台，都会用到这个东西。它解决了频繁登录、验证的过程，也就是用户的一次登录得到其他系统的信任。可以说：一次登录，全站漫游。实现单点登录，说简单一些，就是解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性。因此，也就需要解决以下两点：

• 存储信任
• 验证信任

只要解决了上述两个问题，其实也就解决了SSO。

看到这里，我们不禁会思考，这样很简单啊，将那个信任放置到客户端的Cookie中，就能搞定啊。嗯，确实可以。

但是，这样搞的话，随之而来的问题是：Cookie的安全性和跨域问题。

       对于Cookie的安全性问题，我们一般通过加密Cookie来处理。关于跨域的问题，这种解决方案，确实是硬伤。通过查找资料，也有解决的方法：这种方案的思路就是把这个信任关系存储在客户端，完了都去客户端验证。要实现这个也不一定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了这种存储能力。

      在大型系统中，一般采用在服务端存储信任关系的解决方案：

这种解决方案，就是把信任关系存储在单独的SSO系统中，比如CAS。

一般说来，大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用，称为用户中心。用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。

但是，其中还是有一些问题需要注意：

1. 如何高效存储大量临时性的信任数据
2. 如何防止信息传递过程中被篡改
3. 如何让SSO系统信任登录系统和免登录系统

         对于第一个问题，一般采用Redis这样的分布式缓存方案，既能提供可扩展数据量的机制，也能提供高效的访问。对于第二个问题，一般采用数字签名的方法，要么通过数字证书签名，要么通过类似于MD5的方式。这就需要SSO系统返回免登录URL的时候，对需要验证的参数进行MD5加密，并带上token一起返回，最后需要免登录的系统进行验证信任关系的时候，需要把这个token传给SSO系统，SSO系统通过对token的验证就可以辨别信息是否被修改。最后一个问题，可以通过白名单来处理，说简单点就是：只有在白名单上的系统才能请求产生信任关系。

以上只是提供了些简单的实现技术，但需要强调的是只是技术实现而已，仅仅是为了解决上面谈到的一些问题。