单点登录实现的几种方式

单点登录可以通过以下几种方式实现：基于 Cookie 实现、通过 JSONP 实现、通过页面重定向的方式、使用独立登录系统

基于 Cookie 实现

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

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

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

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

通过 JSONP 实现

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

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

通过页面重定向的方式

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

这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。

使用独立登录系统

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