SSO单点登录

Cookie

https://segmentfault.com/a/1190000004556040

https://www.jianshu.com/p/2879fb0a5b2e

对于浏览器，会存储每个域名的cookie，当访问的时候，会自动将cookie加入。

cookie有过期日期等属性，但是属性是给浏览器用的，不是给server用的，客户端向server传cookie的时候只传值，不传属性

cookie的默认过期时间是会话结束，关闭了浏览器就没有了，这种cookie存在内存中。如果设置了过期时间则存在硬盘中，而且可以浏览器共享。

cookie的存储目录是什么样子？是明文存储吗？

SSO登陆

https://yq.aliyun.com/articles/636281

https://blog.csdn.net/wang379275614/article/details/46337529

用户在使用通过ssoServer的验证之后会收到一个tgc（ticket-grant-cookie），用户就是使用这个tgc来证明自己的身份的。

当用户访问业务系统时，先使用tgc向sso申请一个st（service-ticket），然后将st传给业务系统，业务系统使用st向sso提交验证（验证成功后可能返回一些用户信息）。

第一次登陆的时候，tgc和st是在同一个response中被返回，这样就节省了一次访问。

---

问题？

为什么用户要单独申请一个st向业务系统证明自己的身份，而不是直接使用tgc证明自己的身份？

tgc是证明用户身份的，即使是业务系统也没有权利获知tgc，防止在业务系统泄露tgc或者业务系统恶意使用tgc。

---

问题？

SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？

其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的

如果非要优化的话，可以将token返回给业务系统，让业务系统带着token请求一次sso，免掉了一次客户端的调用。本质上是业务系统主动请求用户信息，而不是简单的被动被回调。

---

第二次访问sso的时候，会发生什么？

“第二次”的描述并不准确，“第二次”其实可以分为两种：

一种是session还没有断开时的第二次访问，这种情况下的第二次访问是不再需要sso参与的。业务系统在session的第一次业务请求中确定了用户的身份之后，之后就可以通过sessionid验证用户身份（或者生成一个业务系统的token）。

一种是session已经断开，因为用户相关的信息会被暂存到session里面，所以这时候业务系统需要再次从sso中请求用户信息，所以需要client再请求sso拿token，需要注意的是这次和第一次相比，client的cookie中残留了上一次的st，sso中也会记录这个st已经登录，所以不需要用户再次输入用户密码。

只要持有tgc或者st就可以伪造客户端登录系统，所以这两个token是至关重要的，所以同一用户的token会被定期刷新。