本文主要对SSO单点登录与CAS、OAuth2.0两种授权协议的关系和原理进行详细说明。
1. 基础概念

术语解释

SSO－Single Sign On，单点登录

TGT－Ticket Granting Ticket，用户身份认证凭证票据

ST－Service Ticket，服务许可凭证票据

TGC－Ticket Granting Cookie，存放用户身份认证凭证票据的cookie

SSO原理概述

SSO组件主要包含：SSO服务器、SSO客户端。SSO服务器主要负责完成用户认证、提供单点登录服务；SSO客户端部署在应用系统（Web应用端与C/S架构模式应用端），用户请求访问应用系统的受保护资源时，需要将请求转向SSO服务器进行身份认证、单点登录服务相关处理。

SSO单点登录访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的Service Ticket。

5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

7. 单点退出：用户退出单点登录。

SSO单点登录访问总共会涉及以上6个步骤，但用户不同的SSO访问可能只会涉及到几个步骤，我们把SSO访问流程我们分为5种实例情况介绍：登录点首次访问、登录点二次访问、单点首次访问、单点二次访问、单点退出。这5种实例应当可以比较全面地展示SSO访问实现的机制。
 

SSO单点登录（Single sign-on）

所谓单点登录就是在多个应用系统中，用户只需登录一次就可以访问所有相互信任的系统。

CAS 中央认证服务（Central Authentication Service）

CAS是由美国耶鲁大学发起的一个企业级开源项目，旨在为WEB应用系统提供一种可靠的单点登录解决方案（WEB SSO）。

OAuth2.0 开放授权（Open Authorization）

OAuth2.0是一个为用户资源授权定义的安全标准，主要用于第三方应用授权登录，由于OAuth1.0标准存在安全漏洞现在已升级到2.0版本。

SSO单点登录与CAS 和OAuth之间有什么区别

SSO仅仅是一种设计架构，而CAS和OAuth是SSO的一种实现方式，他们之间是抽象与具象的关系。

登录点首次访问

说明：用户首次访问”登录点“System1，session中没有用户上下文，于是将请求地址包装为service参数，转向SSO服务器”定向认证“，SSO服务器返回登录页面，用户录入用户名、密码等凭证信息，提交给SSO服务器，SSO服务器进行认证，认证成功后，生成TGT，再根据TGT发放票据ST，返回响应给浏览器，浏览器带着票据ST的service参数的请求，请求SSO服务器验证票据，验证票据成功后，返回给浏览器用户信息（通过cas协议约定的xml格式传递数据解析转换成需要的用户信息），设置session用户上下文、cookie中设置TGC。
 

 登录点二次访问

说明：用户在上述“登录点首次访问”登录成功后，再次访问登录点的应用服务时，判断session中已经存在用户上下文，就不再拦截，直接转向到需要访问的目标服务资源。

单点首次访问

说明：同上述“登录点首次访问”的说明。

单点二次访问

   与“登录点二次访问”相似。
单点退出

说明：用户单点登录后，有一个全局的过滤器SingleSignOutFilter对访问的安全资源的ticket,sessionid记录到一个映射表，我们暂称其为票据会话映射表。在一个子系统(如system1)执行单点退出"/logout"时，先销毁system1的本地session，再向SSO服务器发送单点退出请求，SSO服务器接到这个请求后，将用户认证票据TGT销毁，清除浏览器cookie中的TGC，再读取票据会话映射表，将其对应的票据ST，session全部销毁。这样用户再访问时各子系统时，是单点退出状态，就需要重新登录。

我们再详细从CAS源码中看看SSO单点退出实现机制。

SSO客户端涉及源码类图如下：

2. 单点登录

让我们用两张图来看一下阐述一下单点登录的设计流程

打个比方，SSO 和我们去迪士尼玩时购买的通票很像，我们只要买一次通票，就可以玩所有游乐场内的设施，而不需要在过山车或者摩天轮那里重新买一次票。在这里，买票就相当于登录认证，游乐场就相当于使用一套 SSO 的公司，各种游乐设施就相当于公司的各个产品。

使用 SSO 的优点很明显：

提升用户体验

就以我厂为例。我厂有两个产品，丁香人才网和丁香园论坛，假如你是我厂用户，肯定无法忍受登录丁香园论坛的时候输入一次用户名密码，登录人才网又要输入一次用户名密码吧？

避免重复开发

假如你是我厂后端，每天任务都饱和的不行，肯定无法忍受到人才网开发一套登录逻辑，到论坛又开发一套登录逻辑吧？

提升安全系数

假如你是我厂运维，发现了一个安全隐患需要紧急修复。你肯定无法忍受给茫茫多的产品后端都发一封邮件，责令修复吧？万一漏了一个呢？。

3. CAS 流程

下面让我们用一张图来说明一下用户是如何在两个不同系统中如何实现CAS单点登录的。

CAS系统 （cas.qiandu.com）

门户系统 （www.qiandu.com）

邮箱系统（mail.qiandu.com）

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

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

1. 用户访问邮箱系统，邮箱系统没有登录，跳转到CAS系统。
2. 由于CAS系统已经登录了，不需要重新登录认证。
3. CAS系统生成ST，浏览器跳转到邮箱系统，并将ST作为参数传递给邮箱系统。
4. 邮箱系统拿到ST，后台访问CAS系统，验证ST是否有效。
5. 验证成功后，邮箱系统将登录状态写入session，并在mail.qiandu.com域下写入Cookie。

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

4. OAuth 流程

OAuth2.0的四种授权方式

1. 授权码(authorization code)

这是最常用的一种方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌，项目中常用的就是这种
—这种模式算是正宗的oauth2的授权模式
—设计了auth code，通过这个code再获取token
—支持refresh token

2. 隐藏式(implicit)

允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”，一般应用于纯前端项目
—这种模式比授权码模式少了code环节，回调url直接携带token
—这种模式的使用场景是基于浏览器的应用
—这种模式基于安全性考虑，建议把token时效设置短一些
—不支持refresh token

3. 密码式(resource owner password credentials)

直接通过用户名和密码的方式申请令牌，这方式是最不安全的方式
—这种模式是最不推荐的，因为client可能存了用户密码
—这种模式主要用来做遗留项目升级为oauth2的适配方案
—当然如果client是自家的应用，也是可以
—支持refresh token

4. 凭证式(client credentials)

这种方式的令牌是针对第三方应用，而不是针对用户的，既某个第三方应用的所有用户共用一个令牌，一般用于后台api服务消费者设计
—这种模式直接根据client的id和密钥即可获取token，无需用户参与
—这种模式比较合适消费api的后端服务，比如拉取一些用户信息等
—不支持refresh token

 
5. CAS和OAuth的区别

CAS的单点登录时保障客户端的用户资源的安全，客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS客户端）的资源。

CAS的单点登录，资源都在客户端这边，不在CAS的服务器那一方。用户在给CAS服务端提供了用户名密码后，作为CAS客户端并不知道这件事。随便给客户端个ST，那么客户端是不能确定这个ST是用户伪造还是真的有效，所以要拿着这个ST去服务端再问一下，这个用户给我的是有效的ST还是无效的ST，是有效的我才能让这个用户访问。

OAuth2.0则是保障服务端的用户资源的安全，获取的最终信息是，我（OAuth2.0服务提供方）的用户的资源到底能不能让你（OAuth2.0的客户端）访问。

所以在最安全的模式下，用户授权之后，服务端并不能直接返回token，通过重定向送给客户端，因为这个token有可能被黑客截获，如果黑客截获了这个token，那用户的资源也就暴露在这个黑客之下了。

于是聪明的服务端发送了一个认证code给客户端（通过重定向），客户端在后台，通过https的方式，用这个code，以及另一串客户端和服务端预先商量好的密码，才能获取到token和刷新token，这个过程是非常安全的。

如果黑客截获了code，他没有那串预先商量好的密码，他也是无法获取token的。这样oauth2就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了