1. 什么是单点登录 SSO？
   (1) 英文全称 Single Sign On，简称就是 SSO。它的解释是：在多个应用系统中，只需要登录一 次，就可以访问其他相互信任的应用系统。
   
   如图所示：
         图中有 4 个系统，分别是 App1、App2、App3、和 SSO。App1、App2、App3 没有登录模块，而 SSO 只有登录模块，没有其他的业务模块，当 App1、App2、App3 需要 登录时，将跳到 SSO 系统，SSO 系统完成登录，其他的应用系统也就随之登录了。这完全 符合我们对单点登录（SSO）的定义。

2. 为什么要用单点登录（解决了什么问题）？
   (1) 解决了用户在一个子系统、模块很多的系统中操作，需要多次登录的问题。提高用户体验、 降低了认证和其它业务的耦合性，提高了系统的可维护性。
   (2) 传统的服务器端 Session 登录方式
   

3. 怎么实现 SSO？
   (1) 同域单点登录
   
   一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名叫 做：a.com，同时有两个业务系统分别为：app1.a.com 和 app2.a.com。我们要做单点登录（SSO）， 需要一个登录系统，叫做：sso.a.com。
         我们只要在 sso.a.com 登录，app1.a.com 和 app2.a.com 就也登录了。通过上面的登陆认证机制，我们可以知道，在 sso.a.com 中登录了，其实是在 sso.a.com 的服务端的 session 中记录 了登录状态，同时在浏览器端（Browser）的 sso.a.com 下写入了 Cookie。

这里存在两个问题：

• Cookie 不能跨域。访问 app1.xxx.com 产生的 cookie，不能在 app2.xxx.com 使用。解 决办法是把 Cookie 设置为顶域
• 服务器端 Session 不能共享。解决办法是 Session 共享，例如 Spring-Session 或者 memcached+tomcat 方案
  注意，这不是真正的单点登录

(2) 不同域下的单点登录
    CAS 是 Central Authentication Service 的缩写，*认证服务，一种独立开放指令协议。CAS 是耶鲁大学（Yale University）发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单 点登录方法

具体流程如下：

1. 用户访问 app1，但用户现在没有登录。
2. 跳转到 CAS server，即 SSO 登录系统，以后图中的 CAS Server 我们统一叫做 SSO 系统。SSO 系统也没有登录，弹出用户登录页。
3. 用户填写用户名、密码，SSO 系统进行认证后，将登录状态写入 SSO 的 session，浏览器 （Browser）中写入 SSO 域下的 Cookie。
4. SSO 系统登录完成后会生成一个 ST（Service Ticket），然后跳转到 app1，同时将 ST 作为 参数传递给 app1。
5. app1 拿到 ST 后，从后台向 SSO 发送请求，验证 ST 是否有效。
6. 验证通过后，app1 将登录状态写入 session 并设置 app 域下的 Cookie。

然后，跨域单点登录就完成了。以后我们再访问 app1 时，app 就是登录的。接下来，我们再看看访问 app2 时的流程。
（1）用户访问app2，app2没有登录，跳转到SSO
（2）由于SSO已经登录了，不需要登录重新登录认证
（3）SSO生成ST，浏览器跳转到app2，并将ST作为参数传递给app2
（4）app2拿到ST，后台访问SSO，验证ST是否有效
（5）验证成功后，app2将登录状态写入session，并在app2域下写入Cookie
这样的话app2就不需要走登录流程，就已经是登录的了，SSO，app1以及app2在不同的域，它们之间的session不共享也是没有问题的

问题：
用户在SSO服务器认证成功后，能不能通过回调地址，直接把用户信息返回给app系统，app系统收到后直接设置用户登录Session，然后返回数据给客户端呢？？？

答案是当然不行，加入某用户在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息， 是不是app系统也认为登录了呢？？？这是很可怕的

项目中实现方案：
1，CAS认证 + SpringSecurity授权
CAS官方示例：https://jasigcas.herokuapp.com/cas

CAS 和 OAuth 区别

CAS 的单点登录时保障客户端的用户资源的安全；OAuth2 则是保障服务端的用户资源的安全 CAS客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS 客户端）的资源；OAuth2 获 取的最终信息是，我（OAuth2 服务提供方）的用户的资源到底能不能让你（OAuth2 的客户端）访问 CAS 的单点登录，资源都在客户端这边，不在 CAS的服务器那一方。用户在给 CAS 服务端提供了用 户名密码后，作为 CAS 客户端并不知道这件事。随便给客户端个ST，那么客户端是不能确定这个 ST 是用户 伪造还是真的有效，所以要拿着这个 ST 去服务端再问一下，这个用户给我的是有效的 ST还是无效的 ST， 是有效的我才能让这个用户访问。

OAuth2 认证，资源都在 OAuth2 服务提供者那一方，客户端是想索取用户的资源。

所以在最安全的模式下，用户授权之后，服务端并不能直接返回 token，通过重定向送给客户端，因为 这个 token 有可能被黑客截获，如果黑客截获了这个 token，那用户的资源也就暴露在这个黑客之下了。 于是聪明的服务端发送了一个认证 code 给客户端（通过重定向），客户端在后台，通过 https 的方式， 用这个 code，以及另一串客户端和服务端预先商量好的密码，才能获取到 token 和刷新 token，这个过程是 非常安全的。 如果黑客截获了 code，他没有那串预先商量好的密码，他也是无法获取 token 的。这样 OAuth2 就能 保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了。 所以 cas 登录和 OAuth2 在流程上的最大区别就是，通过 ST 或者 code 去认证的时候，需不需要预先商 量好的密码。