单点登录原理及实现sso

WEB的登录那些事

说道账户登录和注册，其实我们每天都在亲身感受着，像微博、知乎还有简书等等。我们总是需要定期的去重新登录一下，对于这种认证机制，我们都能说出来两个名词，Cookie、Session。的确没错，Cookie和Session是实现这一切的核心。

为什么会有Cookie和Session？区别是什么？
引入这两个概念的根本原因是因为Http协议是无状态的，也就是说它不能建立起多次请求之间的关系。所以需要引入一个能有浏览器或服务器保存的一个上下文状态，也就是Cookie和Session。说到底Session的实现是依赖于Cookie的，因为Cookie是真正的由浏览器保存的状态，Session是利用了JSessionID。在我看来其实两者有差异，但是根本的依赖是一样的。Cookie也是有生命周期的，像Session级别或者有一定“寿命”的Cookie。一切是由浏览器去维护的。

常见的跨域登录问题

之前楼主主要是做账户和Passport这方面的工作，其实在跨域这也是碰见了一些问题。

对于同一个根域下的登录问题

如果我们的站点有不止一个业务，那么他们可能部署在不同的机器上，也往往需要不同的域名进行区分。但是所有的业务又都是依赖于一套账户体系，那么我们这时候需要通过一次登录解决所有站点的登录问题，那么我们这个时候可以使用一个最笨的方法：那就是一次登录成功，将Cookie写到根域下，那么这样所有的站点就能实现，同一个根域下的Cookie共享，自然实现了”单点登录“。

对于多个根域下的登录问题

如果是多个根域名，那么这种情况下上面的机制就不能实现“单点登录”了。因为之所以上面可以实现“单点登录”的效果。是因为浏览器和Http协议的支持。但是对于跨根域的站点之间进行Cookie的共享是比较复杂的。

方法1:登录成功之后将Cookie回写到多个域名下。

这种办法可能十分简单，你可以通过后端的response写，也可以用前端js去写，但是必须有对所有需要“单点登录”的站点进行逐一的写入。用脚想这种办法也是行不通的，因为你需要维护一个站点的列表，维护工作十分复杂，同时对于增加站点也会特别痛苦。对于Cookie的销毁也是十分复杂的，因为还是要对所有域名下的Cookie进行删除。也就是说将原来需要做的工作增加了n倍。对于小型站点这种办法是可取的。

方法２:jsonp

搞过前端的可能都知道用jsonp可以做跨域的请求，而我们解决的就是多个域下的统一登录的问题，好像很顺理成章的样子。但是，登录是Server端做的吧？我们在Client端做跨域的处理，这怎么看也不是很合理。同时这种办法需要很大的维护成本，每一次请求都要去固定的域下取相应的Cookie之后再做请求。想想维护有头疼。

方法3 :引入一个中间态的Server

这种办法算是一个简化版的SSO，实现思想也十分的“狡猾”。但是对于小网站做跨域登录的处理却十分的有用，具体思路如下：

首先，我们有两个域名要实现单点登录，同时我们需要一个中间的Server。

我们有一个系统域名为javahelp.com.cn,当我们登录的时候访问javahelp.com.cn/wp-login进行登录，登录成功之后将Cookie回写到javahelp这个域名下。
我们还有一个系统域名为javaWeb.com，当我们访问inside-javaWeb的时候，我们没有Cookie，那么请求跳转到中间系统jump。此时需要将当前域名带到参数中便于jump校验。这个jump系统是在javahelp域下的即：jump.javahelp.net。这时候就能拿到之前写在javahelp域下的Cookie。
jump系统在收到了xulingbo域下的Cookie之后，取出xulingbo域下的Cookie，并redirect请求jump.inside-javaWeb.net,这个接口也是在jump系统中，请求后jump系统将Cookie回写到inside-javaWeb域名下，这样就实现了简易的单点登录。如下图所示：

@@@

但是这种方式不是很灵活，对于数据传输的安全性没有保障，并且在销毁Cookie的时候无能为力，只能全部遍历的销毁。

方法4：基于CAS的SSO系统

CAS可不是java中的Compare-And-Swap，它是一个开源的单点登录系统(SSO)。实现的机制不算复杂但是思想十分灵巧。用CAS也可以快速实现单点登录。盗图一张说明sso单个域的登录和验证流程：

@@@

CAS主要分为CAS Client 和CAS Server ，其中Client主要是内嵌在需要SSO登录站点的拦截器或过滤器上。

首先浏览器向站点1发起请求。
站点1发现当前请求没有合法的Cookie，那么重定向到CAS Server上，也就是SSO Server。
CAS Server展示登录界面，要求用户登录。
用户登录后，会写CAS Server的Cookie到浏览器，同时生产ticket，利用一个302跳转到CASClient。这样能保证用户无感知。
CAS Client利用生成的ticket发送到CAS Server进行验证，验证通过后，站点1生成自己的Cookie并回写到用户浏览器，然后进行登录成功的跳转。

这样就能保证当前浏览器在站点1的域名下，有站点1的Cookie，同时当前浏览器也有CAS Server的Cookie。

接下来看下站点2的登录：

@@@

站点2，在进行登录时和站点1初次登录流程一致，但是在访问CAS Server的时候，由于当前浏览器已经有了CAS Server的Cookie，那么直接校验通过返回ticket。
ticket通过302跳转跳转到CAS Client上，之后的流程就和站点1是一样的了。如果此时认证失败，那么需要重新走一次登录的过程。

其实感觉很麻烦，但是流程却十分的简单，主要是使用CAS Server的Cookie做校验，同时各自系统维护自己的Cookie。

注意的问题：

CAS Server的Cookie劫持问题，如果CAS Server的Cookie被劫持掉，那么就相当于拿到了一切，所以必须要用HTTPS实现这个过程。
ticket的使用，ticket只能被使用一次，一次校验后立即失效。同时需要有时效性，一般5分钟。最后ticket生成规则要随机，不能被碰撞出来。
对于各自系统自己的Session，也可以依赖于SSO，这样就能保证所有的Session规则一致，便于集中控制。

其实SSO的实现很灵活，CAS只是说了一个原理，至于具体怎么实现，需要平衡安全性、易用性等诸多因素，所以也没有一个固定的实现方案。