必须在连接后立即做授权验证，因为握手阶段认证仅确认初始准入，无法应对用户登出、Token吊销、权限变更或设备劫持等实时风险；连接一旦建立就可能被长期复用，跳过后续授权将导致残留连接被攻击者利用绕过所有校验。

WebSocket 连接建立后不能直接放行业务通信，必须完成授权验证才能保障安全。这不是可选步骤，而是防止未授权连接滥用资源、伪造身份、发起重放或越权操作的关键防线。

为什么必须在连接后立即做授权验证？

握手阶段的认证（如 JWT 校验）只确认“请求连接的人有资格进门”，但无法保证连接建立后持续合法——比如用户已登出、Token 被吊销、权限已变更、设备被劫持。连接一旦打开，就可能被长期复用。若跳过连接后的授权验证，攻击者可利用残留连接绕过后续所有校验。

推荐的连接后授权验证流程

服务端在 WebSocket 握手成功后，主动向客户端发送一条轻量级授权挑战消息，客户端响应后，服务端完成最终授权决策：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 服务端生成唯一、一次性的 nonce 和精确到秒的 expires 时间戳
• 推送挑战消息，例如：{"type":"auth_challenge","nonce":"x9f2a1","expires":30}
• 客户端在本地计算动态响应（如 HMAC-SHA256(nonce + 用户密钥) 取前6位，或展示图形验证码等待人工输入）
• 客户端在 expires 秒内提交响应，如：{"type":"auth_response","code":"482917","nonce":"x9f2a1"}
• 服务端核验 nonce 是否未使用、是否未超时、code 是否匹配；全部通过则标记该连接为“已授权”，加入受信会话池
• 任一校验失败，立即关闭连接（如 ws.close(4003, "Authorization failed")）

如何防止重放与绑定连接

授权验证必须与当前 WebSocket 实例强绑定，避免跨连接复用或中间人截获重放：

• nonce 必须单次有效：服务端用 Redis 或内存缓存记录已用 nonce，验证后立即删除
• 绑定连接标识：将 nonce 与 WebSocket session ID 或底层 TCP socket fd 关联，拒绝非本连接提交的响应
• 不依赖客户端时间：服务端以自身系统时间为基准判断 expires，避免客户端时钟偏差导致误判
• 禁用明文传输敏感因子：用户密钥绝不通过网络传递，仅用于前端本地运算；图形/短信验证码需配合短时效（≤60秒）和单次有效机制

授权状态的生命周期管理

授权不是一次性的终点，而是一个需持续维护的状态：

• 客户端应定时发送心跳（ping），服务端收到后重置该连接的授权有效期（如延长 5 分钟），否则自动过期下线
• 服务端监听用户权限变更事件（如管理员撤权），主动向对应连接推送 {"type":"auth_revoked"} 并关闭连接
• 前端维护 isAuthorized = false 状态，所有业务 send() 前检查该标志；未通过授权时静默丢弃消息，不报错也不重试
• 授权通过后，建议服务端下发一个短期 session token（如 10 分钟有效期），后续消息可携带该 token 做轻量级二次校验，降低每次解析开销