二级域名的单点登录，核心是把Cookie的会话作用域抬高到主域名根域（比如.example.com）；完全跨域到另一个主域名时，则必须引入独立认证中心，用Token代替Cookie会话。这两条路线的实现成本差了一个量级,别选错。
二级域名单点登录怎么实现？先做Cookie根域共享
二级域名之间共享“登录状态”，最直接的办法是让各个子站的Cookie认同一个根域，这算得上一种轻量级的跨域统一认证方案，原理很简单：Cookie自带了Domain和Path属性，浏览器只要看到返回头的Domain匹配，就会把这段Cookie塞进本地仓库；往后的请求，只要目标地址落在该Domain范围内,都会自动带上它。
把Set-Cookie的Domain统一到根域
假设你的主站是example.com，子站是app.example.com和admin.example.com，登录成功后,后端签发Cookie时需要显式指定：
Set-Cookie: session_id=加密串; Domain=.example.com; Path=/; HttpOnly
这里的关键是Domain=.example.com前那个点，带点意味着所有二级子域以及主域本身都能读到这个Cookie，对比一下，如果不设置Domain，Cookie默认只绑定在签发的那个具体域名上，app站登录后，admin站照样要求重新登录。
不少团队的坑也出在这一步：主站和子站分属两套代码仓库，A系统自己写了个Session过滤器，B系统也来一套，结果Cookie里不止一个会话标识，行业共识认为，注册SSO网关时，统一由同一个会话服务签发Cookie，子站只做校验，别自己造Session,操作步骤是：
- 在登录服务中配置统一的Cookie域名参数,写死根域。
- 把会话数据挪到Redis或同类中心化存储,而不是各服务器本地内存。
- 子站收到请求后，从Cookie里取出会话ID,再向认证服务校验。
子域会话同步的细节与坑
根域共享Cookie不等于登录态一定成功，还有两个细节不处理好,二级域名单点登录依然会失败。
HTTPS与Secure标记。 如果你的主站走了HTTPS，Cookie里必须加上Secure属性，否则浏览器在HTTPS请求下压根不会写入，如果子站用的是HTTP，而Cookie要求Secure，浏览器同样拒绝，实践里最常见的情况是测试环境不统一,导致登录态时好时坏。
子域之间如何共享同一个会话存储。 比如用户在a.example.com登录后，会话数据存到了Redis，但b.example.com校验时去连自己本地的Session池，那肯定找不到，很多团队说“明明Cookie一样啊，怎么还是登录失效”，问题大多出在这里，统一把Session标识和缓存中心抽出来,才能让各个子域真正共用一套登录态。
跨域统一认证方案：从CAS到OAuth2/JWT怎么选
离开根域范围，比如公司域名是example.com，但有个业务系统挂在other-company.com，或者你只是把认证交给第三方服务，那就是另一套玩法了，跨域统一认证方案比较成熟的有以下几种,实际落地的难度排序跟域名数量有关。
独立认证中心（CAS）在主域之外单独部署
常见做法是搭一个独立的认证中心，域名比如sso.example.com，所有业务系统都重定向到它,流程很直白：
- 用户请求子站
app.example.com，子站发现无会话，302跳到sso.example.com/login。 - 用户在认证中心登录，认证中心在
sso.example.com域名下种Cookie,同时生成一个一次性ticket。 - 带着ticket跳回
app.example.com，子站拿ticket去认证中心“验票”,换回用户身份。
这种模式下，业务系统本身不碰密码，只负责兜住认证中心的回调，如果你的内部系统多，且技术栈杂乱（Java一套、PHP一套、Go一套），CAS式方案会省心不少，因为各语言都有成熟的CAS Client适配器。
动态订阅请求：跨域统一认证方案做完以后，最直观的感受是“所有系统跟一个大脑连在一起”，用应用市场或者OA系统做入口,体验更顺滑。
OAuth2协议：面向API和第三方应用
跨域统一认证如果还牵涉开放平台或移动App，OAuth2的授权码模式更合适，认证中心负责发Authorization Code（短时效的一次性代码）和Access Token，业务方拿授权码去换Token,再通过Token调取用户信息。
对比CAS，OAuth2的适配更贴近“外网协作”：比如你的官网在
www.example.com，合作伙伴的独立域名通过OAuth2接入你的用户体系，不用共享Cookie，也不共享Session,只共享一个Token校验入口。
这里有一个你必须想清楚的取舍：Token失效了怎么办？多数情况下，访问Token配一个短过期时间（比如2小时），刷新Token配一个长过期时间（比如7天），一旦刷新Token也过期，用户就得重新走一边登录流程，业界里称这个为“静默续期”，但实现起来麻烦,需要前端封装请求队列。
JWT无状态Token：会话数据不落中心化存储
JWT（JSON Web Token）解决的是另一个问题：不想每次验证都查Redis，去认证中心再二次握手，它的商业场景常见于微服务网关里：单点登录时把用户身份和权限写在JWT的payload里，然后用私钥签名，微服务端用公钥验签,不查库。
JWT不是银弹，JWT的无状态带来一个绕不过去的麻烦：签发出去的Token没法主动失效，除非你还维持一份黑名单，很多团队用了JWT才发现“踢人下线”功能根本不好做,最后又兜回来加了一层Redis缓存校验。
业内专家指出，选JWT还是选OAuth2+中心化Session，要看你的团队驾驭服务端状态的能力，如果一堆系统之间查个登录态本来就乱，JWT只会掩盖问题,不会根治。
二级域名和非同根域的业务系统，IT架构选型怎么落
搞清楚了上文,现在做最终决策。
| 方案 | 适用场景 | 实施成本 | 后果不足 |
|---|---|---|---|
| Cookie根域共享 | 主域名 + 多个二级子域 | 低，配置一两个参数 | 跨到别的根域直接失效 |
| CAS独立认证中心 | 内部系统多，且不共根域 | 中等，需要部署一套中心服务 | 受回调地址管理约束 |
| OAuth2授权码 | 面向第三方 / 移动端 | 中高，审批流程和Token管理都要做 | 完整落地周期相对较长 |
| JWT无状态Token | 微服务API，想减少中心查询 | 中，签名密钥管理要严谨 | 无状态，不能强制失效 |
如果你只是在二级域名之间做多系统统一登录，毫不犹豫选第一种：改Set-Cookie的Domain，把Session放到公共Redis，论坛里问“二级域名会话共享问题”的不少，反复折腾到最后,基本都是卡在Redis没共用。
如果你的公司正在规划跨域统一认证方案，而且系统数量超过个位数，建议CAS起手，再留OAuth2的通道给需要接入第三方生态产品的场景，别一上来就复杂化，登录这事越简单,用户流失越少。
多数情况下，企业做多系统统一登录，都是几套内部管理后台之间互通，真金白银花出去的是服务器和写代码的时间，开发一个简单的跨域SSO，一个后端工程师一周能搞定；换成CAS，整个团队配合联调又得一周多，费用主要花在跨团队联调上,工具本身开源。
二级域名的单点登录，和真正意义上的跨域统一认证，本质不一样：前者解决同根域下的共享，后者解决完全隔离的身份映射，认清楚业务需求边界再动手,方向比代码重要。
常见的二级域名单点登录和跨域统一认证问题解答
二级域名单点登录需要哪些前置条件？
至少满足三点：所有子域共享同一个主域名；有可用的会话存储（Redis或数据库）；浏览器必须允许设置Cookie，如果你的系统曾被人用HTTP布过线下环境，记得补上HTTPS，否则Secure属性的Cookie会被拦掉。
微服务单点登录怎么配置跨域？
微服务的网络结构比传统站点复杂，跨域统一认证一般落在网关层，登录成功后，网关统一向Redis写入会话，下放一个短时效的Token（例如JWT）给前端，前端每次请求带上，网关校验成功就转发到下游，下游微服务通过透传请求头拿到用户ID,不再自己管理登录状态。
跨域统一认证方案通常要多少钱？
这个问题要看你的业务体量，如果只是把主站和子站的Cookie统一到根域，零基础直接改配置就能跑通，如果需要搭建CAS或OAuth2认证中心，涉及额外的服务器资源支出、工时甚至密码安全设备，这是按场景开价的事情，市面上几家云厂商都提供SSO服务，小团队用托管服务更省，真正贵的不是软件,而是搭好之后的长期维护。