单点登陆的理解

概念

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

单点登陆大家经常听说，但是又该如何理解呢？现在将这个概念两两拆分解释

单点

借鉴的文章

需求一： 账号在正在设备A上使用（应用是设备A上当前活动应用）, 若设备B上用该账号登录应用，要求设备A上的账号立即退出。 解决办法：
应用客户端上做个定时服务，定时去检测服务端保存的账号最后登录的设备号，如果发现非本机设备号，强制账号退出，并提示用户。 需求二：
账号在正在设备A上使用（应用是设备A上当前活动应用）,
若设备B上用该账号登录应用，不要求设备A上的账号立即退出，当应用重新打开时再自动退出登录。
解决办法：应用启动时检测服务端保存的账号最后登录的设备号，如果发现非本机设备号，强制账号退出，并提示用户。

登陆

借鉴的文章

以Cookie作为凭证媒介

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

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

Cookie不安全 不能跨域实现免登
对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。
对于第二个问题，更是硬伤。

通过JSONP实现

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

Auth via jsonp
这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了，攻击者可以在本地建立一个实现了登录接口的假冒父应用，通过绑定Host来把子应用发起的请求指向本地的假冒父应用，并作出回应。
因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。

通过页面重定向的方式

最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。
父应用提供一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。

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

推荐文章

利用redis来实现身份验证的一种方法，类似session机制

http://blog.csdn.net/clareqi/article/details/52689115

App的token机制

http://www.cnblogs.com/20000ding/p/5278255.html

app后端怎么设计用户登录方案

http://blog.csdn.net/newjueqi/article/details/44062849