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