网站跨站点单点登录的实现
前言
网站的用户身份验证往往使用 Cookie 技术。用户在一个网站进行登录以及身份验证的过程一般为：
- 在登录页面进行登录后，将登录用户的用户名等信息加密后写在本地浏览器中，也就是一个 Cookie，我们把这个 Cookie 叫做票（Ticket）。
- 需要判断用户是否登录的页面，需要读取相应 Ticket，并从中解密出用户信息，如果 Ticket 不存在或者无法解密出有意义的内容，意味着用户没有登录，或者登录信息不正确，这时就要跳转到登录页面进行登录。
- 加密 Cookie 的作用有两个，一是防止用户信息被不怀好意者看到，二是保证 Ticket 无法被伪造，后者更为重要。
跨站点设置 Cookie 的一个关键用途就是跨站单点登录，也就是用户在一个站点登录之后，可以在另一个站点直接获取登录状态。
实现方法
实现跨站单点登录要分为
跨子域
和
完全跨域
两种情况。
跨子域(Across-Subdomains)
所谓跨子域是指站点之间位于同一个父域下，如：https://a.2000.com 与 https://b.2000.com 位于同一个父域
2000.com
下。
跨子域登录的步骤与普通登录时完全相同，只是写 Cookie 时需要将 Cookie 的域写为需要跨站单点登录的站点之间共同的父域。如：
cookie.domain="2000.net"
，这样子域之间就自然可以共享 Cookie 了。
要注意的是，用户退出登录时，删除 Cookie 一定要删除域为父域的 Cookie，从而让跨站单点登录的所有网站全部退出登录状态。
完全跨域(Across-Domains)
完全跨域是指站点之间没有共同的父域，如 https://a.2000.com 与 https://b.2001.com。这时就需要借助一个
验证站点
，需要跨站单点登录的站点在验证失败时，将跳转到专门的验证站点进行登录，使用同一个验证站点的 Ticket 来判断用户是否登录。
首先上一张概念图：
从图中可以看到，我们有三个模块：用户浏览器客户端，需要实现跨站单点登录的站点们（a.2000.com、b.2001.com…），验证站点（passport.2021.com）。
咱们一个个地分析：
用户首次单点登录
为图中黑色线条且带序号的步骤（1~6）。
- 用户访问 A 站点的网页
- A 站点读取用户浏览器的 A-Ticket（A 站点验证用户身份的票据），由于用户是首次登录，所以浏览器没有 A-Ticket。导致验证失败，这时网页跳转到 P 站点的验证模块。
- P 站点同样读取用户浏览器的 P-Ticket，同样没有，验证失败。重定向到 P 站点的登录处理页面，此时，用户需要按照页面提示完成登录。
-
用户登录成功后，P 站点生成 P-Ticket 并写入浏览器。接着页面跳转到 A 站点的登录处理模块，并携带用户在 P 站点时的登录信息，从而
直接触发
A 站点的登录处理，由于用户身份已经在 P 站点验证通过了，所以 A 站点的登录也必然是成功的，登录后，A 站点同样会生成 A-Ticket 并将其写到用户浏览器中。 - A 站点隐式登录成功后，重定向到开始的验证模块。
- 此时，用户浏览器已经拥有了 A-Ticket，所以成功判断用户为已登录状态，可以进行跳转。
用户跨站访问
用户在 A 站点单点登录（其实是在 P 站点完成的）后，首次对 B 站点进行访问。
- 浏览器中没有 B-Ticket，所以 B 站点验证失败。跳转到 P 站点的验证模块。
- P 站点读取用户浏览器中的 P-Ticket，进行验证后发现用户已经登录过了，便直接携带从 P-Ticket 中解密得到的用户信息跳转到 B 站点的登录处理。同样可以通过 B 站点的登录，此时，B 站点也会生成 B-Ticket 并将其写到用户浏览器中。
- B 站点隐式登录成功后，重定向到用户最初访问的页面，此时，用户浏览器已经拥有了 B-Ticket，所以成功判断用户为已登录状态。
用户退出登录
一般来说，删除用户当前访问的站点的 Ticket 和 P-Ticket 即可。
结语
对跨站设置 Cookie 实现单点登录的方法进行简要介绍。
参考资料
https://www.cnblogs.com/huaxingtianxia/p/6236804.html
如有差错，敬请指正。