了解单点登录的前置内容，请先阅读：

单点登录，在企业的应用中是多样的。上篇文章中，我们提到企业的一个域名承载着不同的应用。但随着企业对新业务的探索，便会申请一些新的域名用于功能承载，一方面为了做区分，另一方面为了满足监管要求。在这种不同域名的模式下，打通原先站点的用户体系，就是本次介绍的 —— 不同域下的单点登录。

不同域名 SSO 原理设计

认证系统根据浏览器的登录信息，进行身份认证。如果通过，返回给浏览器一个证明 [ 认证系统_ticket ]，再通过浏览器将 [ 认证系统 _ticket ] 发送到到各个应用设置相应 cookie 的 url，并返回给浏览器一个证明 [ 应用系统 _ticket ]，再重定向到最初访问的页面，以后应用系统就可以自动登录。

不同域名 SSO 原理分析

实现单点登录说到底就是要解决如何产生和存储这个信任，以及其他系统如何验证这个信任的有效性，要点就是这两个点：存储信任、验证信任。

• 以 Cookie 作为凭证媒介，存放用户凭证
  用户登录父应用之后，应用返回一个加密的 cookie，当用户访问子应用的时候，携带这个 cookie，授权应用解密 cookie 并进行校验，校验通过则登录当前用户。
• 通过JSONP 实现
  JSONP 可以实现跨域问题，用户在父应用中登录后，跟 Session 匹配的 Cookie 会存到客户端中，当用户登录子应用时，授权应用访问父应用提供的 JSONP 接口,并在请求中带上父应用域名下的 Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用解析返回的加密信息来验证用户，如果通过验证则登录用户。
• 通过页面重定向
  通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。父应用提供一个 GET 方式登录接口，用户通过子应用重定向连接的方式访问这个接口，登录后则声称加密的 Token，并重定向到子应用提供的验证 Token 的接口，通过解密和校验后，子应用登录当前用户。
• 使用独立登录系统
  大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个用户中心应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。

不同域名 SSO 验证方式

凭借 cookie，应用间的重定向

用户在上面三个站点中的任意一个站点登录成功时，必须在浏览器中同时设置其他站点的 cookie 信息。

1. 用户登录 site1 站点，并且验证通过之后，浏览器会存储一份 site1 站点的 cookie 信息。
2. 在用户登录 site1 站点的请求响应之前，需要从 site 1 站点重定向到 site2 站点和 site3 站点去设置 cookie 信息。
3. 浏览器设置site2 站点和 site3 站点的 cookie 信息。
   登录其中一个站点在浏览器设置 cookie ,同时其他站点都在浏览器设置对应 cookie，就可以实现单点登录了，单点退出是一样的原理，一个退出清除 cookie，其他也清除。

借助单独的 SSO 服务器

借助单独的 SSOServer，浏览器只需要保存 SSOServer 的 cookie 信息。当浏览器对任意一个站点请求时，都会先重定向到 SSOServer 去验证当前用户的 cookie 是否存在，若存在，将验证成功后的跳转页面发送给浏览器，否则将跳转到登录页面提示用户登录。

下面分为三部分来介绍：

CAS

在不同域下来实现单点登录，CAS 是实现 SSO 单点登录的框架。
CAS（Central Authentication Service），即中央认证服务，它通过跳转中间域名的方式来实现登录。