SSO实际上就是通过用户的一次性鉴别登录，在实际操作中我们有不同的方法来实现SSO，下面我们主要讲的是用 CAS 实现 SSO 。

1.  用户访问产品 a，域名是 www.a.cn。
2. 由于用户没有携带在 a 服务器上登录的 a cookie，所以 a 服务器返回 http 重定向，重定向的 url 是 SSO 服务器的地址，同时 url 的 query 中通过参数指明登录成功后，回跳到 a 页面。重定向的url 形如 sso.dxy.cn/login?service=https%3A%2F%2Fwww.a.cn。
3. 由于用户没有携带在 SSO 服务器上登录的 TGC（看上面，票据之一），所以 SSO 服务器判断用户未登录，给用户显示统一登录界面。用户在 SSO 的页面上进行登录操作。
4. 登录成功后，SSO 服务器构建用户在 SSO 登录的 TGT（又一个票据），同时返回一个 http 重定向。这里注意：
5. 重定向地址为之前写在 query 里的 a 页面。
6. 重定向地址的 query 中包含 sso 服务器派发的 ST。
7. 重定向的 http response 中包含写 cookie 的 header。这个 cookie 代表用户在 SSO 中的登录状态，它的值就是 TGC。
8. 浏览器重定向到产品 a。此时重定向的 url 中携带着 SSO 服务器生成的 ST。
9. 根据 ST，a 服务器向 SSO 服务器发送请求，SSO 服务器验证票据的有效性。验证成功后，a 服务器知道用户已经在 sso 登录了，于是 a 服务器构建用户登录 session，记为 a session。并将 cookie 写入浏览器。注意，此处的 cookie 和 session 保存的是用户在 a 服务器的登录状态，和 CAS 无关。
10. 之后用户访问产品 b，域名是 www.b.cn。
11.  由于用户没有携带在 b 服务器上登录的 b cookie，所以 b 服务器返回 http 重定向，重定向的 url 是 SSO 服务器的地址，去询问用户在 SSO 中的登录状态。
12. 浏览器重定向到 SSO。注意，第 4 步中已经向浏览器写入了携带 TGC 的cookie，所以此时 SSO 服务器可以拿到，根据 TGC 去查找 TGT，如果找到，就判断用户已经在 sso 登录过了。
13. SSO 服务器返回一个重定向，重定向携带 ST。注意，这里的 ST 和第4步中的 ST 是不一样的，事实上，每次生成的 ST 都是不一样的。
14. 浏览器带 ST 重定向到 b 服务器，和第 5 步一样。
15. b 服务器根据票据向 SSO 服务器发送请求，票据验证通过后，b 服务器知道用户已经在 sso 登录了，于是生成 b session，向浏览器写入 b cookie。

如图所示，至此，整个登录流程结束。之后当用户访问 a 或者 b 后，直接会携带 a cookie/b cookie，就不用再向 SSO 确认了。

实际开发时，可以根据 CAS 增加更多的判断逻辑，比如，在收到CAS Server签发的ST后，如果 ST 被 hacker 窃取，并且 client 本身没来得及去验证 ST，被 hacker 抢先一步验证 ST，怎么解决。此时就可以在申请 ST 时添加额外验证因子（如ip、sessionId等）。