10年的时候在iteye的第一篇文章记录了一下当时怎么实现我们系统的单点登陆。不过那个时候文章写的不好，思路也很浮躁，很难看懂，在csdn的第一篇技术博客打算重新温顾一下当时实现单点登陆的思路。先来看看什么叫单点登陆

单点登录(Single Sign On)，简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。 --百度百科

为什么要实现单点登陆？

从10年新版改造后，我们把一些辅助功能垂直切分成单独的应用，跑在不同的应用服务器集群中。实现单点登陆，以保证各个应用间共享登陆状态和用户信息。

使用cookie实现单点登陆会遇到哪些问题？

第一个问题是cookie的过期时间设置的问题，要实现单点登陆，有很多种方式，我们采用让根域名下的所有的应用共享cookie信息，设置cookie的过期时间时，有两种情况：一种是过期时间为一个小于等于零的数值，这样,cookie的信息是保存在内存中的，浏览器关闭，cookie信息就失效了。但是如果浏览器一直不关闭，cookie信息会一直在内存中不失效，这将给用户的账户安全带来极大的隐患。另外一种是过期时间为一个正数，设置成正数时，cookie信息会保存在用户的硬盘上，在cookie还未过期时，即使用户关闭浏览器，只要重新打开浏览器访问，cookie信息会被重新读取，登陆状态恢复。这样，也会存在安全隐患。仅仅通过cookie来实现单点登陆，还是存在风险的！正数不好，零和负数也不好，那设置成啥值呢？又该用怎么样的方式来解决呢？实际上我们使用cookie+memcached有两种实现方式供参考。

1、模仿session的会话维护的方式，用户关闭浏览器，或者会话时间一段时间内不活动，会话就断开了。我们将cookie的过期时间设置为一个小于等于0的数值，这样在用户关闭浏览器时，会话就结束了。而将用户信息保存到memcache中，如果用户30分钟不活动，memcached中的值自动过期，用户的会话也就结束了。所以判断用户的会话信息是否有效时需要经过两个逻辑，一个是判断cookie信息是否有效，一个是看memcached中是否有用户信息。两个条件都符合用户的会话才有效。但是这种用法会有一个问题：memcachd是缓存，在设置过期时间创建之后，一到了过期时间，不管用户的cookie信息是否依然存在，用户是否依然在活动，memcached的信息依然会删除。这就导致了用户活动一段时间之后又要重新登录。所以用户活动每次获取登录状态时都要重新设置用户信息到缓存中。这个就解决了我们上面说的cookie信息的风险的问题。

2、使用memcached只用来保存用户信息，以免太过频繁的通过接口取用户数据，而为了解决cookie过期的问题，我们还需要将系统的时间long值保存在cookie的信息中。以此要记录用户最后一次活动的时间，再根据逻辑判断用户的活动时间是否超过了指定的时间段。这个很好理解，我把你这次活动的时间保存在cookie里面，当你下一次活动时，再把上次保存的时间取出来，加上我指定的会话过期的时长，比如20分钟，是否在当前时间之前，如果是，那会话就过期了，需要重新登录。这样每次用户活动是需要刷新的是cookie，而不是memcached信息了，这样memcached的缓存时间可以自行设定。

第二个问题是cookie的安全问题。cookie始终是在用户的浏览器保存的，是由客户端来管理的，现在找个能修改cookie信息的工具非常容易，怎么来防止cookie信息被篡改以保证单点登陆的安全？我们采用了互联网中最为普遍的验证签名的方式来进行的，将登陆的cookie信息使用一个MD5(私钥+信息字符)的算法，这样，我们的cookie信息如果被删除了，会话断开了。如果被篡改了，验签不通过，会话也断开。

cookie+memcached方式实现单点登陆的整体流程(图画的弱爆了，不献丑了)

以cookie控制过期的方式为例子，memcached控制过期的方式反三一下。用户登录时，生成COOKIE信息sso_login:memberId|time|Md5(info) 和设置缓存，用户每进行一次请求，首先取出COOKIE，验证签名数据，取出COOKIE的生成时间与现在的时间进行对比，验证是否过期；再次，若验证通过则获取缓存中的用户信息并重新生成cookie,主要是刷新cookie的生成时间，若验证不通过或者过期，则进入用户登录流程。关键点都在那个cookie的格式上了，cookie的格式为 cookie.name=sso_login,value=memberId|time|Md5(info)