单点登录（SSO）

什么是单点登录

单点登录的英文名叫做：Single Sign On（简称 SSO）。
在以前的时候，一般我们就单系统，所有的功能都在同一个系统上。

img
后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。

img
比如阿里系的淘宝和天猫，很明显地我们可以知道这是两个系统，但是你在使用的时候，登录了天猫，淘宝也会自动登录。简单来说，单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。

回顾单系统登录

在我初学 Java Web 的时候，登录和注册是我做得最多的一个功能了（初学 Servlet 的时候做过、学SpringMVC 的时候做过、跟着做项目的时候做过…），反正我也数不清我做了多少次登录和注册的功能了…这里简单讲述一下我们初学时是怎么做登录功能的。

众所周知，HTTP 是无状态的协议，这意味着服务器无法确认用户的信息。于是，W3C 就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是 Cookie。如果说 Cookie 是检查用户身上的“通行证”来确认用户的身份，那么 Session 就是通过检查服务器上的“客户明细表”来确认用户的身份的。Session 相当于在服务器中建立了一份“客户明细表”。HTTP 协议是无状态的，Session 不能依据 HTTP 连接来判断是否为同一个用户。于是：服务器向用户浏览器发送了一个名为 JESSIONID 的 Cookie，它的值是 Session 的 id 值。其实 Session 是依据 Cookie 来识别是否是同一个用户。所以，一般我们单系统实现登录会这样做：

  • 登录：将用户信息保存在 Session 对象中
    • 如果在 Session 对象中能查到，说明已经登录
    • 如果在 Session 对象中查不到，说明没登录（或者已经退出了登录）
  • 注销（退出登录）：从 Session 中删除用户的信息
  • 记住我（关掉浏览器后，重新打开浏览器还能保持登录状态）：配合 Cookie 来用

Java 的 demo，供参考：

用户登录：

img

用户退出：

img

拦截器：

img

总结一下上面代码的思路：

  1. 用户登录时，验证用户的账户和密码

  2. 生成一个 Token 保存在数据库中，将 Token 写到 Cookie 中

  3. 将用户数据保存在 Session 中

  4. 请求时都会带上 Cookie，检查有没有登录，如果已经登录则放行

多系统登录的问题及解决方案

session 不共享问题

单系统登录功能主要是用 Session 保存用户信息来实现的，但我们清楚的是：多系统即可能有多个 Tomcat，而 Session 是依赖当前系统的 Tomcat，所以系统 A 的 Session 和系统 B 的 Session 是不共享的。

img

解决系统之间 Session 不共享问题有以下几种方案：

  • Tomcat 集群 Session 全局复制（集群内每个 tomcat 的 session 完全同步）【会影响集群的性能，不建议】

  • 根据请求的 IP 进行 Hash 映射到对应的机器上（这就相当于请求的 IP 一直会访问同一个服务器）【如果服务器宕机了，会丢失了一大部分 Session 的数据，不建议】

  • 把 Session 数据放在 Redis 中（使用 Redis 模拟 Session）【建议】

我们可以将登录功能单独抽取出来，做成一个子系统：

img

SSO系统的逻辑如下：

登录功能（SSO 单独的服务）：

img
其他子系统登录时，子系统请求 SSO系统进行登录，将返回的 token 写到 Cookie 中，下次访问时则把 Cookie 带上：

img

总结：

  • SSO 系统生成一个 token，并将用户信息存到 Redis 中，并设置过期时间

  • 其他系统请求 SSO 系统进行登录，得到 SSO 返回的 token，写到 Cookie 中

  • 每次请求时，Cookie 都会带上，拦截器得到 token，判断是否已经登录

到这里，其实我们会发现其实就两个变化：

  • 将登录功能抽取为一个系统（SSO），其他系统请求 SSO 进行登录

  • 本来将用户信息存到 Session，现在将用户信息存到 Redis

cookie 跨域的问题

上面我们解决了 Session 不能共享的问题，但其实还有另一个问题：Cookie 是不能跨域的。比如说，我们请求< https://www.google.com/ >时，浏览器会自动把 google.com 的Cookie 带过去给 google 的服务器，而不会把< https://www.baidu.com/ >的 Cookie 带过去给 google 的服务器。这就意味着，由于域名不同，用户向系统 A 登录后，系统 A 返回给浏览器的 Cookie，用户再请求系统 B 的时候不会将系统 A 的 Cookie 带过去。

针对 Cookie 存在跨域问题，有几种解决方案：

  • 服务端将 Cookie 写到客户端后，客户端对 Cookie 进行解析，将 Token 解析出来，此后请求都把这个 Token 带上就行了

  • 多个域名共享 Cookie，在写到客户端的时候设置 Cookie 的 domain

  • 将 Token 保存在 SessionStorage 中（不依赖 Cookie 就没有跨域的问题了）

CAS 原理

说到单点登录，就肯定会见到这个名词：CAS （Central Authentication Service），下面说说 CAS 是怎么搞的。如果已经将登录单独抽取成系统，我们还能这样玩。现在我们有两个系统，分别是[www.java3y.com和www.java4y.com，一个 SSO[www.sso.com]

img

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

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

img

3.随后，认证中心重定向回系统 A，并把 Token 携带过去给系统 A，重定向的地址如下：www.java3y.com?token=xxxxxxx

4.接着，系统 A 去 SSO 认证中心验证这个 Token 是否正确，如果正确，则系统 A 和用户建立局部会话（创建 Session）。到此，系统 A 和用户已经是登录状态了。

img

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

6.注意，因为之前用户与认证中心 [www.sso.com已经建立了全局会话]（当时已经把 Cookie 保存到浏览器上了），所以这次系统 B 重定向到认证中心是可以带上Cookie的。认证中心根据带过来的 Cookie 发现已经与用户建立了全局会话了，认证中心重定向回系统 B，并把 Token 携带过去给系统 B，重定向的地址如下：www.java4y.com?token=xxxxxxx

7.接着，系统 B 去 SSO 认证中心验证这个 Token 是否正确，如果正确，则系统 B 和用户建立局部会话（创建 Session）。到此，系统 B 和用户已经是登录状态了。

img

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

JWT

概念

JWT全称是Json Web Token。是一种跨域认证解决方案，属于一个开放的标准。它规定了一种Token实现方式，目前多用于前后端分离项目和OAuth2.0业务场景。