单点登录
SSO（Single Sign On）
说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。
单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下两个：
1. 存储信任
2. 验证信任
如果一个系统做到了开头所讲的效果，也就算单点登录，单点登录有不同的实现方式，本文就罗列我开发中所遇见过的实现方式。
初级：以Cookie作为凭证媒介
最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。
用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。
不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：
1. Cookie不安全
2. 不能跨域实现免登
对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。对于第二个问题，更是硬伤。
中级：通过JSONP实现
对于跨域问题，可以使用JSONP实现
传送门：
（如果不知道JSONP是什么？）
。
用户在父应用中登录后，跟Session匹配的Cookie会存到客户端中，当用户需要登录子应用的时候，授权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。
这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了，攻击者可以在本地建立一个实现了登录接口的假冒父应用，通过绑定Host来把子应用发起的请求指向本地的假冒父应用，并作出回应。因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。
高级：通过页面重定向的方式
最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。
父应用提供一个GET方式的登录接口
A
(
此时的父应用接口固定，攻击者无法去伪造
)，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证
Token
的接口
B
(
此时的子应用接口固定，攻击者无法去伪造
)，通过解密和校验之后，子应用登录当前用户。
这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。安全与方便，本来就是一对矛盾。
总结：使用独立登录系统
一般说来，大型应用会把
授权的逻辑
与
用户信息的相关逻辑
独立成一个应用，称为用户中心。
用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。
# 附录
分析：
SSO（单点登录）
与
OAuth2.0(授权)
的区别？
SSO（单点登录）
OAuth2.0(授权)
oauth2.0
1、解决的是服务提供方（如：微信等）给第三方应用授权的问题
2、是一种具体的协议，只是为用户资源的授权提供了一个安全的、开放而又简易的标准。OAuth 2.0为客户端开发者开发Web应用，桌面端应用程序，移动应用及客厅设备提供特定的授权流程。
3、通俗的讲，OAuth是为解决不同公司的不同产品实现登陆的一种简便授权方案，通常这些授权服务都是由大客户网站提供的，如QQ，新浪微博，人人网等。而使用这些服务的客户可能是大客户网站，也可能是小客户网站。使用OAuth授权的好处是，在为用户提供某些服务时，可减少或避免因用户懒于注册而导致的用户流失问题
sso
1、解决的是大型系统中各个子系统如何共享登陆状态的问题
2、是一种技术，可以用cookie实现，在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统
3、通常处理的是一个公司的不同应用间的访问登陆问题。如企业应用有很多业务子系统，只需登陆一个系统，就可以实现不同子系统间的跳转，而避免了登陆操作。
参考文献
传送门：
单点登录原理
传送门：
oauth2详解