同源策略·跨域与身份认证（Cookie / Session / Token）
前节 浏览器同源与 CORS，后节 会话与凭证。
第一部分：同源策略与跨域
同源定义
协议、主机名、端口 三者完全一致才算同源；任一不同即为 跨域。
同源策略限制脚本读取 跨源响应数据、跨源 DOM、以及默认 跨站 Cookie 行为等，用于降低窃取风险。
仍能「加载」但未必能「读」
<script> / <img> / <link> / <video> 等可跨域 加载展示，但 JS 读取跨域响应内容（如 fetch、Canvas 读像素）会受阻，除非服务端放行。
CORS（跨域资源共享）
由 服务端响应头 声明允许的来源与方法：
Access-Control-Allow-Origin（勿滥用*搭配凭证请求）Access-Control-Allow-Methods、Access-Control-Allow-Headers- 带 Cookie 时需
Allow-Credentials: true且来源精确
预检 OPTIONS：非简单请求先发预检，通过后再发真实请求。
常见解决路径
| 方式 | 说明 |
|---|---|
| 后端配置 CORS | 正规 API 跨域首选 |
| 开发代理 | devServer 同源转发，仅开发环境 |
| 反向代理 | Nginx 同域转发，生产常用 |
小结
跨域是 浏览器策略，不是「前端一行代码关掉」。前端 credentials: 'include' 必须与后端 CORS 精确配合。
第二部分：Cookie、Session、Token 与单点登录
HTTP 无状态，登录态靠 Cookie / Session / Token 等机制衔接。
Cookie
- 存储：浏览器按域名保存，体积约 4KB 量级；可设
HttpOnly（防 XSS 读）、Secure（仅 HTTPS）、SameSite（跨站携带策略）。 - 传输：匹配到的 Cookie 会 自动附加 到请求（受同源/跨站策略约束）。
Session
- 服务端保存用户状态，浏览器通常只存
sessionId（多在 Cookie 里）。 - 优点：状态集中，可强制下线；缺点：集群需 共享存储（如 Redis）。
- 风险面：依赖 Cookie 时注意 CSRF，需 Token 或 SameSite 等配合。
Token（如 JWT）
- 客户端存放（Header
Authorization/ 存储介质），服务端 校验签名即可 无会话存储（刷新令牌策略另议）。 - 优点：跨域、分布式友好；缺点：泄露即可用直到过期，需 短有效期 + 刷新 + HTTPS；XSS 若窃取存储中的 Token 仍是风险。
选型对比（简）
| 维度 | Session | Token |
|---|---|---|
| 状态 | 服务端有状态 | 常做无状态校验 |
| 扩展 | 需会话共享 | 易水平扩展 |
| 注销 | 服务端删会话即可 | 需黑名单或短 TTL |
单点登录（SSO）提要
多系统共享一次登录：统一认证中心 签发票据或 Token；同主域可用 domain 级 Cookie；跨域常用 中心登录页回调 + Token，或 OAuth2/OIDC 标准流程。
前端常见辅助：重定向到 IdP、postMessage 同步（需校验 origin）、iframe 静默检测（注意浏览器第三方 Cookie 限制）。
小结
没有万能方案：Cookie+Session 适合传统同域；前后端分离 / 多端 常见 Token + HTTPS + CSRF/XSS 防护组合拳。