单点登录（一）—— 单点登录及常见解决方案原理（CAS、oauth2、JWT）

背景

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

概念

单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。例如，网页登录了淘宝账号，天猫，钉钉等阿里系应用都不用再二次登录了。 SSO核心意义就一句话：一处登录，处处登录；一处注销，处处注销。就是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，即用户只需要记住一组用户名和密码就可以登录所有有权限的系统。

可使用一幅图形象表现有误单点登录的系统的区别

技术实现

基于Cookie的单点登录

这是最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。
不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：
Cookie不安全
不能跨域实现免登

对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie
的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。

对于第二个问题，不能跨域实现免登更是硬伤。因此，有了基于Session的单点登录

基于Session的单点登录

Session解决了Cookie不能跨域的问题，但也存在其他问题。早期的单体应用使用Session实现单点登录，但现在大部分情况下都需要集群，由于存在多台服务器，Session在多台服务器之间是不共享的，因此，还需解决Session共享的问题

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

Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）【会影响集群的性能呢，不建议】
根据请求的IP进行Hash映射到对应的机器上（这就相当于请求的IP一直会访问同一个服务器）【如果服务器宕机了，会丢失了一大部分Session的数据，不建议】
分布式Session，即把Session数据放在Redis中（使用Redis模拟Session）【建议】

由上可以得出，当前大部分单点登录系统运行流程如下图

用户登录系统应用1，发现未登录，重定向到认证系统登录，认证系统验证用户名和密码等信息通过，返回用户一个ticket，并将Session存入Redis或其他缓存容器
用户携带ticket登录系统应用2，应用系统2到认证系统进行ticket验证，若存在该ticket对应的Session，则登录成功
用户携带ticket登录系统应用3，应用系统3到认证系统进行ticket验证，若存在该ticket对应的Session，则登录成功

常见方案

CAS

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，是单点登录的一种现方式，分为CAS服务端和CAS客户端

具体流程如下：

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

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

用户访问app2系统，app2系统没有登录，跳转到SSO。
由于SSO已经登录了，不需要重新登录认证。
SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
app2拿到ST，后台访问SSO，验证ST是否有效。
SSO系统返回验证结果
验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。
这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

oauth2（第三方登录授权）

OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息

主要应用于第三方应用授权登录：在APP或者网页接入一些第三方应用时，时常会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录,第三方应用通过oauth2方式获取用户信息

详细步骤如下（以微信登录为例）：

用户访问第三方网站,第三方应用需要用户登录验证,用户选择微信授权登录
第三方应用发起微信登录授权请求
微信服务器拉起用户授权确认页面
用户授权通过
微信发送请求到第三方应用redirctUrl(第2步填写redirct_uri参数),返回凭证code与state(第2步自定义)
第三方应用获取到code之后,根据code获取accessToken
根据accessToken获取用户信息
对用户信息进行处理(用户是否第一次登录,保存用户信息,自定义token,session处理等)
返回结果(步骤1对应url或者重定向到首页)

JWT（客户端token）

难度较大，需要了解很多协议
Json web token (JWT)，是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标（(RFC
7519)。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
基于JWT认证协议，自己开发SSO服务和权限控制。

以上为常见的单点登录解决方案，当然，在使用的同时也会和其他的权限授权认证的安全框架整合实现，常见的安全框架有

Spring Security
Shiro

部分内容引用自
[1] https://yq.aliyun.com/articles/636281
[2] https://www.jianshu.com/p/4f5fcddb4106