单点登录

Posted 2023-05-26 october-sy

1、概念

单点登录SSO，说的是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。

2、单点登录的要点

存储信任；
验证信任；

3、实现单点登录的三种方式

（1）以cookie作为凭证

最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。

用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie进行校验，校验通过则登录当前用户。

缺点：

cookie不安全

通过加密可以保证安全性，但如果对方掌握了解密算法就完蛋了。

不能跨域实现免登

（2）通过JSONP实现

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

缺点：

这种方法虽然能解决跨域问题，但是治标不治本，没有解决cookie安全性的问题。

（3）通过页面重定向的方式

最后一种介绍的方式，是通过父应用和子应用来回重定向进行通信，实现信息的安全传递。

父应用提供一个GET方式的登录接口A（此时的父应用接口固定，攻击者无法去伪造），用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个登录页面，用户输入账号密码进行登录，如果用户已经登录了，则生成加密的token，并且重定向到子应用提供的验证token的接口B（此时的子应用接口固定，攻击者无法去伪造），通过解密和校验之后，子应用登录当前用户。

缺点：

这种方式较前面的两种方式，是解决了安全性和跨域的问题，但是并没有前面两种方式简单，安全与方便，本来就是矛盾的。

4、使用独立登录系统

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

5、sso（单点登录）与OAuth2.0（授权）的区别？

（1）sso（单点登录）

通常处理的是一个公司的不同应用间的访问登录问题，如企业应用有很多子系统，只需登录一个系统，就可以实现不同子系统间的跳转，而避免了登录操作；
通过cookie、jsonp、重定向来实现；

（2）OAuth2.0（授权）

解决的是服务提供方（如微信）给第三方应用授权的问题，简称微信登录；
是一种具体的协议，只是为用户资源的授权提供了一个安全的、开放的而又简易的标准，OAuth2.0（授权）为客户开发者开发web应用，桌面应用程序，移动应用及客厅设备提供特定的授权流程。

话说单点登录

参考技术A 在企业发展初期，企业使用的系统很少，通常一个或者两个，每个系统都有自己的登录模块，运营人员每天用自己的账号登录，很方便。 但随着企业的发展，用到的系统随之增多，运营人员在操作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于运营人员 来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。

单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

如图所示，图中有4个系统，分别是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他的业务模块，当Application1、Application2、Application3需要登录时，将跳到SSO系统，SSO系统完成登录，其他的应用系统也就随之登录了。这完全符合我们对单点登录（SSO）的定义。

在说单点登录（SSO）的技术实现之前，我们先说一说普通的登录认证机制。

如上图所示，我们在浏览器（Browser）中访问一个应用，这个应用需要登录，我们填写完用户名和密码后，完成登录认证。这时，我们在这个用户的session中标记登录状态为yes（已登录），同时在浏览器（Browser）中写入Cookie，这个Cookie是这个用户的唯一标识。下次我们再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户是否登录。如果不做特殊配置，这个Cookie的名字叫做jsessionid，值在服务端（server）是唯一的。

一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名叫做：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。那么我们怎么才能让app1.a.com和app2.a.com登录呢？这里有两个问题：

那么我们如何解决这两个问题呢？针对第一个问题，sso登录以后，可以将Cookie的域设置为顶域，即.a.com，这样所有子域的系统都可以访问到顶域的Cookie。我们在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。比如：我们不能在自己的系统中给baidu.com的域设置Cookie。

Cookie的问题解决了，我们再来看看session的问题。我们在sso系统登录了，这时再访问app1，Cookie也带到了app1的服务端（Server），app1的服务端怎么找到这个Cookie对应的Session呢？这里就要把3个系统的Session共享，如图所示。共享Session的解决方案有很多，例如：Spring-Session。这样第2个问题也解决了。

同域下的单点登录就实现了，但这还不是真正的单点登录。

同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？

这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。

上图是CAS官网上的标准流程，具体流程如下：

至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

有的同学问我，SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？

其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。

单点登录（SSO）的所有流程都介绍完了，原理大家都清楚了。总结一下单点登录要做的事情：

参考自己写的【关于JWT/TOKEN】文章