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来证明自己的身份的。
• 当用户访问业务系统时（app.com），
  • 302到sso（携带了tgc）
  • sso验证tgc后，重定向到业务系统，并通过url返回1个属于业务系统的st（service-ticket）app.com?st=12345678
  • 业务系统使用st向sso提交验证，验证通过后再cookie中设置一个sessionid，后续同session的请求通过session进行验证。
• 第一次登陆的时候，tgc和st是在同一个response中被返回，这样就节省了一次访问。

---

tgc是属于sso-server的cookie。只会向SSO服务器发送tgc（即使是业务系统也没有权利获知tgc）。为了防止业务系统A恶意登录业务系统B。

st是属于业务系统的cookie，生命周期一般是几天。每个业务系统会有自己的st。业务系统通过st向SSO服务器验证用户身份。

JsessionId是业务系统的cookie，生命周期是session级别。同一个session中的第1次请求通过st进行验证，第2次请求则通过JsessionID验证。

---

问题：验证通过后将秘钥存在cookie中，后续客户端通过秘钥访问业务系统？

• 业务系统a和业务系统b可能存在跨域问题。
• 业务系统a和业务系统b使用相同的秘钥，意味着a系统可以恶意访问b系统

---

问题？

SSO系统登录后，SSO返回浏览器一个st，然后浏览器拿token再次访问业务系统，业务系统再拿ST再次访问SSO进行验证，这个步骤好像有点多余。若果SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？

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

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

---

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

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

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

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

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