WebSocket JWT鉴权必须在握手阶段完成，因连接升级后无法返回401中断；需在HTTP Upgrade时解析校验Token，URL传参须短期专用且严格验签，Header方式受限于浏览器需代理注入，Token应独立获取并绑定jti与aud。
WebSocket 的 JWT 鉴权必须在握手阶段完成，连接建立后再校验 Token 属于无效防护 —— 这不是“能不能做”，而是“做了也白做”。
为什么不能等连接建立后再验证 JWT
WebSocket 握手完成后，连接已升级为长生命周期的二进制帧通道，此时服务端无法像 HTTP 那样返回 401 并中断连接。常见错误现象包括：
- 客户端调用
new WebSocket(url)后立即收到open事件，但服务端尚未校验身份 - 未授权连接持续占用内存、FD 和心跳资源，可能被用于广播攻击或连接耗尽
- 业务层收到第一条消息才开始验证 Token，此时非法用户已拿到连接句柄
正确做法是：在 TCP 连接发起、HTTP Upgrade 请求到达时，就完成 JWT 解析与拒绝逻辑。Spring Boot 要覆盖 HandshakeInterceptor，uWebSockets.js 要在 upgrade 回调里处理，Node.js + ws 库则需从 request.url 或 request.headers 提前读取并校验。
URL 参数传 token 的实操要点
这是兼容性最好、前端最易实现的方式，但有明确风险边界：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
token必须是短期专用凭证（如 15 分钟），不能复用登录态长期 JWT - 服务端解析时要严格检查
exp、iat、签名，并查 Redis 黑名单确认未吊销 - 浏览器地址栏、Nginx
$request_uri日志、CDN access log 默认会记录完整 URL，敏感环境禁用 - 前端拼接示例：
new WebSocket("wss://api.example.com/ws?token=" + encodeURIComponent(wsToken))—— 注意必须encodeURIComponent，否则含.或+的 JWT 会解析失败
Header 方式更安全但需绕过浏览器限制
标准 WebSocket 构造函数不支持传自定义 header，所以直接写 new WebSocket(url, { headers: {...} }) 会报错。可行路径只有两条：
- 用
fetch发起带Authorization: Bearer <token>的请求，再调用response.upgrade()（仅现代 Chromium 支持，Firefox 不支持） - 通过反向代理注入：Nginx 配置
proxy_set_header Authorization "Bearer $arg_token";，后端从 upgrade request 的 headers 里读Authorization
服务端验证时注意：Bearer <token> 中 Bearer 和 token 之间必须是一个空格，多一个少一个都会导致解析失败；且 token 本身不能被二次 URL 编码。
Token 获取与存储不能和登录态混用
把 localStorage 里存的登录 JWT 直接塞进 WebSocket URL，等于把长期凭证暴露在可被 XSS 窃取的上下文中。应该：
- 单独提供
POST /api/v1/ws-token接口，该接口要求携带 HttpOnly Cookie 或已有 Authorization header - 响应头设置
Cache-Control: no-store, no-cache，禁止 CDN 或浏览器缓存 - 前端用
fetch拿到 token 后立即用于 WebSocket 连接，不落地存储 - 服务端生成时绑定
jti（唯一 ID）和aud: "websocket"，避免被挪用到其他接口
真正容易被忽略的是：JWT 里的 exp 是服务端时间戳，而 WebSocket 连接可能持续数小时，如果 token 有效期只设 5 分钟，又没配套刷新机制，连接会在中途静默断开 —— 这种失效不可见，调试时只会看到 close code 1006，得翻服务端日志才能定位到鉴权失败。
