目录

• 背景
• 原理
  • 经典CAS原理图
  • 详细SSO原理图

---

系列总目录

• 业务场景实战汇总

---

背景

• 但随着企业的发展，用到的系统随之增多，运营人员在操作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于运营人员来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。
• 企业的发展过程中应用也会越来越来，SSO单点登录除了内部还可以用在对外系统

---

原理

经典CAS原理图

• 图中CAS client可以理解成我们的业务系统SDK，CAS server可以理解成登录微服务, 完成后会给浏览器下发TGC。如果跨域的话可以用header解决cookie跨域问题

  
  CAS经典图.png
• 名称解析

1. TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST), TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。
2. Cookie中的TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中。浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT
3. ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值

详细SSO原理图

• 官方CAS图

  
  cas详细原理图.png
• 具体流程

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

• 已访问过的流程

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

---

参考文章

• CAS单点登录原理分析(一)
• 单点登录（SSO）看这一篇就够了
• 跨域解决方案 （含header、cookie跨域）