SSO笔记

SSO目录

提示：SSO有两种实现方式

---

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、SSO是什么？

单点登录，Single Sign On（SSO）指的是在多个应用系统中，只需登录一次，就可以访问其他相互信任的应用系统。
如图，SSO 是抽出登录的模块，App1，App2 只负责应用模块，SSO只负责登录模块。App1，App2 需要登录时，将跳到 SSO 系统，SSO 系统完成登录，其他的应用系统也就随之登录了。应用单点登录在大型网站里使用得非常频繁，例如，阿里旗下有淘宝、天猫、支付宝、阿里巴巴等网站。对于背后的成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，单点登录是很有必要的需求。

SSO 应用核心设计

前台站点：业务站点A、业务站点B（需要登录的站点）

SSO站点：登录、退出

SSO服务：登录（登录服务）、登录状态（提供登录状态校验/登录信息查询的服务）、退出（用户注销服务）

数据库：存储用户账户信息

缓存：存储用户的登录信息，通常使用 Redis

二、做法步骤

1. 同企业域名下多个系统登录认证（单点登录）

通过二级域名来区分各个子业务系统、来实现单点登录。 (其实上的跟传统意义上的客户端跟服务端交互记录session状态、写入cookie一样)
此时会出现两个问题：cookie 不能跨域，session 不共享 ? ? ?
SSO 登录以后，可以将 cookie 的域设置为顶域，即 a.com。这样所有子域的系统都可以访问到顶域的 cookie。我们在 sso 系统登录状态，这时再访问 app1，cookie 也带到了app1 的服务（Server）。app1 的服务端怎么找到这个 cookie 对应的 session ？这里需要把两个 app 系统的 session 共享，共享 session 的解决方案有很多 例如： redis、mapcahe等，
做法：通过巧用 cookie 顶域的特性，和 session 共享 实现单点登录。

2.不同域下的系统登录认证（单点登录）

app1 系统登录的流程：
用户访问 app 系统，app 系统是需要登录的，但用户现在没有登录。
跳转到 CAS server，即 SSO 登录系统， SSO 系统也没有登录，弹出用户登录页。
用户填写用户名、密码，SSO 系统进行认证后，将登录状态写入 SSO 的 session，浏览器（Browser）中写入 SSO 域下的 Cookie。
SSO 系统登录完成后会生成一个ST（Service Ticket），然后跳转到 app 系统，同时将 ST 作为参数传递给 app 系统。
app 系统拿到 ST 后，从后台向 SSO 发送请求，验证 ST 是否有效。
验证通过后，app 系统将登录状态写入 session 并设置 app 域下的 cookie。
app2 系统时的流程：
用户访问 app2 系统，app2 系统没有登录，跳转到 SSO。
由于 SSO 已经登录了，不需要重新登录认证。
SSO 生成 ST ，浏览器跳转到 app2 系统，并将 ST 作为参数传递给 app2。
app2 拿到 ST，后台访问 SSO，验证 ST 是否有效。
验证成功后，app2 将登录状态写入 session，并在 app2 域下写入 Cookie。

---

总结

提示：这里对文章进行总结：

一般分为以上两种情况.