sso单点登录的实现。

单体架构的登录：通过cookie和session的会话机制。

缺点：服务器要存储登录信息。

sso单点登录：

实现方式一：父域 Cookie

​         在将具体实现之前，我们先来聊一聊 Cookie 的作用域。

        Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。 如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

缺点：1.服务器要集中存储大量登录信息（用redis实现）。

               2.要共享主域。

实现方式二：认证中心

说到单点登录，就肯定会见到这个名词：CAS （Central Authentication Service），下面说说CAS是怎么搞的。

如果已经将登录单独抽取成系统出来，我们还能这样玩。现在我们有两个系统，分别是www.java3y.com和www.java4y.com，一个SSOwww.sso.com

首先，用户想要访问系统Awww.java3y.com受限的资源(比如说购物车功能，购物车功能需要登录后才能访问)，系统Awww.java3y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：

www.sso.com?service=www.java3y.com
sso认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心建立全局会话（生成一份Token，写到Cookie中，保存在浏览器上）

随后，认证中心重定向回系统A，并把Token携带过去给系统A，重定向的地址如下：

www.java3y.com?token=xxxxxxx
接着，系统A去sso认证中心验证这个Token是否正确，如果正确，返回登录用户的信息，则系统A和用户建立局部会话（创建Session）。到此，系统A和用户已经是登录状态了。

此时，用户想要访问系统Bwww.java4y.com受限的资源(比如说订单功能，订单功能需要登录后才能访问)，系统Bwww.java4y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：

www.sso.com?service=www.java4y.com
注意，因为之前用户与认证中心www.sso.com已经建立了全局会话（当时已经把Cookie保存到浏览器上了），所以这次系统B重定向到认证中心www.sso.com是可以带上Cookie的。

认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，认证中心重定向回系统B，并把Token携带过去给系统B，重定向的地址如下：

www.java4y.com?token=xxxxxxx
接着，系统B去sso认证中心验证这个Token是否正确，如果正确，返回登录用户的信息，则系统B和用户建立局部会话（创建Session）。到此，系统B和用户已经是登录状态了。

看到这里，其实SSO认证中心就类似一个中转站。