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 认证中心。你去 B 系统B 说“我不认识你”把你踢回总服务台。总服务台发现你之前在 A 系统已经登过了于是给你发一张带有时效性的“临时门票”Ticket把你送回 B 系统。B 系统拿着这张门票去 Redis总后台里核对“这张票是真的吗”核对无误后B 系统才让你登录。优缺点既支持跨域名安全性又高Ticket 是一次性的防劫持兼顾性能比模式一稍微复杂一点中间会有页面的跳转重定向。 模式三HTTP 请求主动查询跨域 跨 Redis【大白话比喻】每次办事前先打个电话给总部“人工核实”身份。适用场景子系统不仅域名不同连后台的 Redis 数据库也是各自独立的比如 Java 写的 A 系统和 PHP 写的 B 系统或者完全跨公司的合作系统。工作原理既然内存Redis都不互通那就只能靠“打电话”HTTP 网络请求来沟通了。你在 B 系统登录时B 系统会直接发起一个 HTTP 请求远程呼叫 SSO 认证中心“喂这个用户现在在你们那登录了吗”认证中心查一下自己的数据库回复 B 系统“是的他登录了这是他的账号信息。”B 系统收到回复后才允许你通过。优缺点通用性最强不管你的系统是用什么语言写的、部署在哪里只要能联网发 HTTP 请求就能对接但每次都要跨网络去查询速度相对较慢对认证中心的网络压力也最大。 三种模式对比总结为了更直观地对比为大家整理了一个简单的决策表格模式核心技术适用场景优缺点模式一共享 Cookie同主域名 同 Redis体验最好但限制多必须同域模式二URL 重定向 Ticket不同域名 同 Redis最推荐跨域且安全兼顾性能模式三HTTP 远程查询不同域名 不同 Redis万能兼容但速度慢网络开销大 选型建议如果你的系统都在同一个主域名下闭眼选模式一。如果是现代互联网常见的跨域微服务架构SpringBoot Vue/React首选模式二。只有在面对极其复杂的异构系统不同语言、不同公司、无法共享缓存时才考虑使用模式三。