您的位置: 首页  >  文章  >  spring security oauth2 单点登录资料整理( 技术选型：CAS与oauth2对比）

spring security oauth2 单点登录资料整理( 技术选型：CAS与oauth2对比）

分类: 文章 • 2023-03-12 23:49:32

CAS协议和工作流程下图是 CAS 最基础协议：spring security oauth2 单点登录资料整理( 技术选型：CAS与oauth2对比）

1 、 CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求， CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5 ， 6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。


2 、在该协议中，所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。


3 、 CAS 如何实现 SSO
当用户访问另一服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1) 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；

2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。


另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

OAuth 2.0的运行流程如下图

摘自RFC 6749。spring security oauth2 单点登录资料整理( 技术选型：CAS与oauth2对比）

  1. （A）用户打开客户端以后，客户端要求用户给予授权。

    （B）用户同意给予客户端授权。

    （C）客户端使用上一步获得的授权，向认证服务器申请令牌。

    （D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

    （E）客户端使用令牌，向资源服务器申请获取资源。

    （F）资源服务器确认令牌无误，同意向客户端开放资源。

    不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

    下面一一讲解客户端获取授权的四种模式。

    四种授权方式

    OAuth 2.0定义了四种授权方式。

    • 密码模式（resource owner password credentials）
    • 授权码模式（authorization code）
    • 简化模式（implicit）
    • 客户端模式（client credentials）

    密码模式（resource owner password credentials）(为遗留系统设计)(支持refresh token)

    • 这种模式是最不推荐的，因为client可能存了用户密码
    • 这种模式主要用来做遗留项目升级为oauth2的适配方案
    • 当然如果client是自家的应用，也是可以
    • 支持refresh token

    授权码模式（authorization code）(正宗方式)(支持refresh token)

    • 这种模式算是正宗的oauth2的授权模式
    • 设计了auth code，通过这个code再获取token
    • 支持refresh token

    简化模式（implicit）(为web浏览器应用设计)(不支持refresh token)

    • 这种模式比授权码模式少了code环节，回调url直接携带token
    • 这种模式的使用场景是基于浏览器的应用
    • 这种模式基于安全性考虑，建议把token时效设置短一些
    • 不支持refresh token

    客户端模式（client credentials）(为后台api服务消费者设计)(不支持refresh token)

    • 这种模式直接根据client的id和**即可获取token，无需用户参与
    • 这种模式比较合适消费api的后端服务，比如拉取一组用户信息等
    • 不支持refresh token，主要是没有必要

    refresh token的初衷主要是为了用户体验不想用户重复输入账号密码来换取新token，因而设计了refresh token用于换取新token

    这种模式由于没有用户参与，而且也不需要用户账号密码，仅仅根据自己的id和**就可以换取新token，因而没必要refresh token

  1. cas（单点登录）
    现象：多个系统只需登录一次，无需重复登录
    原理：授权服务器，被授权客户端
    1、授权服务器（一个）保存了全局的一份session，客户端（多个）各自保存自己的session
    2、客户端登录时判断自己的session是否已登录，若未登录，则（告诉浏览器）重定向到授权服务器（参数带上自己的地址，用于回调）
    3、授权服务器判断全局的session是否已登录，若未登录则定向到登录页面，提示用户登录，登录成功后，授权服务器重定向到客户端（参数带上ticket【一个凭证号】）
    4、客户端收到ticket后，请求服务器获取用户信息
    5、服务器同意客户端授权后，服务端保存用户信息至全局session，客户端将用户保存至本地session
  2. oauth2（登录授权）
    现象：第三方系统访问主系统资源，用户无需将在主系统的账号告知第三方，只需通过主系统的授权，第三方就可使用主系统的资源（如：APP1需使用微信支付，微信支付会提示用户是否授权，用户授权后，APP1就可使用微信支付功能了）
    原理：主系统，授权系统（给主系统授权用的，也可以跟主系统是同一个系统），第三方系统
    1、第三方系统需要使用主系统的资源，第三方重定向到授权系统
    2、根据不同的授权方式，授权系统提示用户授权
    3、用户授权后，授权系统返回一个授权凭证（accessToken）给第三方系统【accessToken是有有效期的】
    4、第三方使用accessToken访问主系统资源【accessToken失效后，第三方需重新请求授权系统，以获取新的accessToken】
  3. 单一登录
    现象：同一系统，同一用户在同一时间内只能有一个会话（即一个用户只有一个在使用的浏览器）
    原理：
    1、把登录成功的用户放入session和缓存，缓存中格式：key:userID,value:sessionId
    2、用户访问资源时，用拦截器（或过滤器）拦截用户请求，先判断用户是否已登录（根据session判断），若用户未登录，则定向到登录页面提示用户登录
    3、若用户session已登录，根据用户userID取出缓存数据，判断当前浏览器的sessionId与缓存的是否一致，若一致，则继续访问
    4、若sessionId不一致，则将当期的session数据清空，用户登出，提示用户被踢出


相关推荐