单点登陆的三种实现方式 转自： https://blog.csdn.net/python_tty/article/details/53113612

单点登陆SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登陆后，就不用在其余系统中登陆，也就是用户的一次登陆能获得其余全部系统的信任。单点登陆在大型网站里使用得很是频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操做或交易可能涉及到几十个子系统的协做，若是每一个子系统都须要用户认证，不只用户会疯掉，各子系统也会为这种重复认证受权的逻辑搞疯掉。实现单点登陆说到底就是要解决如何产生和存储那个信任，再就是其余系统如何验证这个信任的有效性，所以要点也就如下两个：

• 存储信任
• 验证信任

若是一个系统作到了开头所讲的效果，也就算单点登陆，单点登陆有不一样的实现方式，本文就罗列我开发中所碰见过的实现方式。

以Cookie做为凭证媒介

最简单的单点登陆实现方式，是使用cookie做为媒介，存放用户凭证。用户登陆父应用以后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，受权应用解密cookie并进行校验，校验经过则登陆当前用户。

不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易使人质疑：

• Cookie不安全
• 不能跨域实现免登

对于第一个问题，经过加密Cookie能够保证安全性，固然这是在源代码不泄露的前提下。若是Cookie的加密算法泄露，攻击者经过伪造Cookie则能够伪造特定用户身份，这是很危险的。对于第二个问题，更是硬伤。

经过JSONP实现

对于跨域问题，可使用JSONP实现。用户在父应用中登陆后，跟Session匹配的Cookie会存到客户端中，当用户须要登陆子应用的时候，受权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登陆状态，返回加密的信息，子应用经过解析返回来的加密信息来验证用户，若是经过验证则登陆用户。

这种方式虽然能解决跨域问题，可是安全性其实跟把信任存储到Cookie是差很少的。若是一旦加密算法泄露了，攻击者能够在本地创建一个实现了登陆接口的假冒父应用，经过绑定Host来把子应用发起的请求指向本地的假冒父应用，并做出回应。由于攻击者彻底能够按照加密算法来伪造响应请求，子应用接收到这个响应以后同样能够经过验证，而且登陆特定用户。

经过页面重定向的方式

最后一种介绍的方式，是经过父应用和子应用来回重定向中进行通讯，实现信息的安全传递。父应用提供一个GET方式的登陆接口，用户经过子应用重定向链接的方式访问这个接口，若是用户尚未登陆，则返回一个的登陆页面，用户输入帐号密码进行登陆。若是用户已经登陆了，则生成加密的Token，而且重定向到子应用提供的验证Token的接口，经过解密和校验以后，子应用登陆当前用户。

这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，可是并无前面两种方式方便。安全与方便，原本就是一对矛盾。

使用独立登陆系统

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