PostMessage 仅是跨域通信通道，不提供认证能力；安全令牌交换必须由服务端统一签发校验JWT，前端只负责原样传递并配合origin校验、nonce防重放等机制。
PostMessage 本身不提供认证能力，它只是跨域通信的通道。安全的令牌交换必须结合服务端验证、严格的源检查、短期有效的令牌和防重放机制，不能仅靠前端 postMessage 实现“认证”。
明确角色与信任边界
子域间通信不是无条件互信。例如 a.example.com 和 b.example.com 同属 example.com，但它们的 JS 代码彼此不可信。真正的认证必须由后端统一签发和校验令牌（如 JWT），前端只负责传递和转交。
关键原则：
- 令牌必须由可信服务端生成（含签名、过期时间、aud 字段限定接收方）
- 发送方页面不解析或验证令牌内容，只原样转发
- 接收方页面收到消息后，立即将令牌连同自身上下文（如当前 origin、session ID）提交给自己的后端做二次校验
- 禁止在 postMessage 中传输明文密码、长期密钥或用户凭证
使用 postMessage 安全传递令牌的操作要点
以 a.example.com 向 b.example.com 发送登录态令牌为例：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
-
严格校验 event.origin：接收方必须比对
event.origin === 'https://a.example.com'，禁用通配符（'*'）或正则模糊匹配 -
验证 event.source 是否可信：可配合
window.frames或预存引用比对，防止伪造 source -
消息结构带类型与随机 nonce：例如
{ type: 'AUTH_TOKEN', token: 'ey...', nonce: 'abc123', timestamp: 171... }，接收方校验 nonce 是否未使用过、时间戳是否在 30 秒窗口内 -
发送方调用 targetWindow.postMessage() 时指定目标 origin：如
iframe.contentWindow.postMessage(data, 'https://b.example.com')，避免被中间域截获
服务端必须承担的核心校验职责
前端 postMessage 只是搬运工，以下校验必须由接收方子域的服务端完成：
- 验证 JWT 签名是否由主认证服务（如 auth.example.com）签发
- 检查
aud（audience）是否精确等于本子域（如"b.example.com"） - 确认
exp未过期、nbf已生效、jti未被重放（需服务端记录已用 jti） - 将令牌与当前用户 session 绑定，拒绝同一令牌多次用于不同会话
- 返回的响应（如 set-cookie 或 API token）应设置
Domain=.example.com且Secure、HttpOnly（若为 Cookie）
替代更安全的现代方案
若控制所有子域，优先考虑更健壮的方案：
-
第一方 Cookie 共享：后端统一设置
Domain=.example.com的认证 Cookie，各子域自动携带，无需前端传令牌 - OAuth 2.0 / OIDC 隐式或 PKCE 流程：由中央授权服务器（auth.example.com）直接向各子域重定向并颁发令牌，规避跨子域 JS 通信风险
- Shared Worker + BroadcastChannel（同源限制）：仅适用于同协议+同端口+同主域，不解决跨子域问题
-
使用 iframe 嵌入中央认证页：通过
window.parent.postMessage由可信 iframe 向父页面（各子域）分发令牌，降低暴露面
不复杂但容易忽略：postMessage 是裸管道，安全令牌交换的本质是前后端协同——前端严守边界、服务端闭环校验。离开后端参与的“前端认证”都是幻觉。
