入门到精通Java SSO单点登录原理详解

1. 基础概念

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的一种实现方式，他们之间是抽象与具象的关系。

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就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了

到此这篇关于入门到精通Java SSO单点登录原理详解的文章就介绍到这了,更多相关SSO单点登录内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论