Sa-Token 单点登录（SSO）三种模式大白话详解：告别重复登录

🚀 Sa-Token 单点登录（SSO）三种模式大白话详解：告别重复登录

在现代分布式系统架构中，我们经常会遇到这样的痛点：公司内部有商城、论坛、后台管理等多个子系统。用户在 A 系统登了一遍，去 B 系统还得再输一次密码，体验极差。

单点登录（Single Sign-On, SSO）就是为了解决这个问题而生的——用户只需在一个地方登录，即可畅通无阻地访问所有互信的系统。

而在 Java 生态中，Sa-Token 凭借其极其简洁优雅的 API 设计，成为了实现 SSO 的热门选择。今天，我们就用大白话来彻底搞懂 Sa-Token 提供的三种 SSO 模式，帮你快速选型！

🏗️ 核心架构原则

在深入模式之前，我们需要明确一个整体架构原则：集中式认证 + 分布式会话管理。简单来说，就是有一个统一的“认证中心”负责验明正身，而各个子系统通过共享或查询的方式来确认用户的登录状态。

🍪 模式一：共享 Cookie（同域 + 同 Redis）

【大白话比喻】：办一张“全园区通用”的门禁卡。

• 适用场景：你的几个子系统都在同一个主域名下（例如oa.example.com和crm.example.com），并且后台连接的是同一个 Redis 数据库。
• 工作原理：因为大家属于同一个“家族”（主域名相同），浏览器允许它们共享 Cookie。你在认证中心登录后，服务器把登录凭证（Token）写进 Cookie，并把这个 Cookie 的作用域设为整个园区（.example.com）。当你去访问其他子系统时，浏览器会自动带上这张通用的门禁卡，子系统一看是自家兄弟发的卡，直接放行。
• 优缺点：实现最简单，用户完全无感，体验最丝滑；但限制最多，必须是同一家族（同主域名）的系统才能用。

🎟️ 模式二：URL 重定向 + Ticket（跨域 + 同 Redis）

【大白话比喻】：去“总服务台”领一张一次性的“入园门票”。

• 适用场景：子系统分散在不同的域名（比如www.aaa.com和www.bbb.com），但后台依然连接着同一个 Redis。这是目前前后端分离及微服务架构中最主流的模式。
• 工作原理：因为域名不同，Cookie 没法直接共享了。这时候需要一个“总服务台”（SSO 认证中心）。
  1. 你去 B 系统，B 说“我不认识你”，把你踢回总服务台。
  2. 总服务台发现你之前在 A 系统已经登过了，于是给你发一张带有时效性的“临时门票”（Ticket），把你送回 B 系统。
  3. B 系统拿着这张门票去 Redis（总后台）里核对：“这张票是真的吗？”核对无误后，B 系统才让你登录。
• 优缺点：既支持跨域名，安全性又高（Ticket 是一次性的，防劫持），兼顾性能；比模式一稍微复杂一点，中间会有页面的跳转（重定向）。

📞 模式三：HTTP 请求主动查询（跨域 + 跨 Redis）

【大白话比喻】：每次办事前，先打个电话给总部“人工核实”身份。

• 适用场景：子系统不仅域名不同，连后台的 Redis 数据库也是各自独立的（比如 Java 写的 A 系统和 PHP 写的 B 系统，或者完全跨公司的合作系统）。
• 工作原理：既然内存（Redis）都不互通，那就只能靠“打电话”（HTTP 网络请求）来沟通了。
  1. 你在 B 系统登录时，B 系统会直接发起一个 HTTP 请求，远程呼叫 SSO 认证中心：“喂，这个用户现在在你们那登录了吗？”
  2. 认证中心查一下自己的数据库，回复 B 系统：“是的，他登录了，这是他的账号信息。”
  3. B 系统收到回复后，才允许你通过。
• 优缺点：通用性最强，不管你的系统是用什么语言写的、部署在哪里，只要能联网发 HTTP 请求就能对接；但每次都要跨网络去查询，速度相对较慢，对认证中心的网络压力也最大。

📊 三种模式对比总结

为了更直观地对比，为大家整理了一个简单的决策表格：

💡 选型建议：

• 如果你的系统都在同一个主域名下，闭眼选模式一。
• 如果是现代互联网常见的跨域微服务架构（SpringBoot + Vue/React），首选模式二。
• 只有在面对极其复杂的异构系统（不同语言、不同公司、无法共享缓存）时，才考虑使用模式三。