本文记录一下在前端通过cookie来实现单点登录的流程，通过一个用户中心和两个业务系统为例子，在cookie同域的情况下来共享cookie从而实现token的传输。
同源的概念
先了解下同源的概念
同源（Same-Origin Policy, SOP）是一种浏览器的安全机制，限制从一个源加载的文档或脚本与另一个源的资源进行交互。同源的定义基于三个要素：协议、域名和端口号。只有这三个要素都相同的资源才被认为是同源的。
如果两个 URL 的协议、域名和端口号任意一个不同，则它们被认为是不同源。例如：
http://example.com/page1和http://example.com/page2是同源的。http://example.com和https://example.com是不同源的（协议不同）。http://example.com和http://sub.example.com是不同源的（域名不同）。http://example.com:80和http://example.com:8080是不同源的（端口号不同）。
Cookie的作用域
Cookie 的作用域确实主要由 Domain 和 Path 决定，而与协议和端口无关
Domain 和 Path 决定 Cookie 作用域：
Domain：指定 Cookie 适用的域名。当多个服务在同一个域名下（即使是不同端口），只要Domain相同，浏览器会发送该 Cookie 给所有匹配的子域。Path：指定 Cookie 生效的路径。只要路径匹配，浏览器就会在相同Domain下发送 Cookie。
协议和端口：Cookie 的存取不受协议（HTTP/HTTPS）和端口的直接影响。浏览器在同一个域名下的所有端口间共享 Cookie，只要 Domain 和 Path 匹配。
解决的场景
根据以上的信息我们可以实现一个前端的单点登录，比如有一个用户中心，和两个业务系统
三个系统之间都是挂载在相同的ip上面，只是端口不同
那么即可实现我只需要在用户中心登录一次，获取到token之后能和两个业务系统
当我在用户中心登录的时候，都是相同的Ip，此时用户中心的端口是 9798
当进入业务系统端口味18087的情况下，可以看到相同的cookie也在这个业务系统中
这是因为用户中心和业务系统的cookie通过Domain这个属性进行了共享
可以借助cookie的这个属性来实现一下token的共享，从而实现从用户中心登录之后，跳转到其他业务系统免登录的场景。
大概的流程就是在业务系统中获取一下token，如果存在token则验证token的正确性直接进入首页，如果不存在token，则走正常的登录页面登录流程
安全问题
由于上面保存的是token登录凭证，为了防止被截获或者篡改，需要注意cookie的其他几个属性
1.设置 HttpOnly 属性可以防止 JavaScript 访问 Cookie，从而降低 XSS（跨站脚本）攻击的风险。
2.使用 Secure 属性确保 Cookie 仅通过 HTTPS 传输，避免在网络上传输时被窃取。
3.设置 SameSite 属性可以限制 Cookie 在跨站请求中的使用，从而降低 CSRF（跨站请求伪造）攻击的风险。
也可以针对我们的cookie来设定较短的过期时间（Expires 或 Max-Age），以降低 token 被盗后长期有效的风险
