做生活的创作者1. WebSocket 鉴权基础与挑战
WebSocket 作为现代实时通信的核心技术，其鉴权机制的设计直接影响着应用的安全性和用户体验。与传统的 HTTP 请求不同，WebSocket 连接一旦建立就会保持长时间的持久连接，这使得传统的基于请求-响应的鉴权模式不再适用。
1.1 WebSocket 鉴权的特殊性
在 HTTP 协议中，每个请求都是独立的，服务器可以在处理每个请求时进行鉴权。这种无状态的特性使得鉴权逻辑相对简单直接。但 WebSocket 的工作机制完全不同：
- 连接持久性：一个 WebSocket 连接可能持续数小时甚至数天
- 双向通信：客户端和服务器都可以随时主动发送消息
- 状态保持：连接建立后，服务器需要维护会话状态
这种特性带来了几个关键挑战：
- 初始鉴权后，如何确保后续通信的安全性？
- 长时间运行的连接中，如何管理凭证的有效期？
- 网络不稳定时，如何优雅地处理鉴权失效和重连？
1.2 常见的安全威胁
在设计 WebSocket 鉴权方案时，我们需要防范以下几类安全威胁：
中间人攻击：攻击者可能拦截 WebSocket 连接，窃取或篡改通信内容。解决方案是强制使用 WSS（WebSocket Secure）协议，即基于 TLS 加密的 WebSocket。
会话劫持：如果鉴权令牌被泄露，攻击者可以冒充合法用户。这要求我们：
- 令牌要有合理的有效期
- 采用安全的传输方式
- 实现令牌吊销机制
重放攻击：攻击者可能捕获并重复发送有效的请求。防御措施包括：
- 使用一次性随机数（nonce）
- 消息时间戳验证
- 请求签名
1.3 Electron 应用的额外考量
Electron 应用作为桌面客户端，有其特殊的运行环境和安全需求：
本地存储安全：
- 避免明文存储敏感信息
- 使用系统提供的安全存储机制
- Windows：使用 DPAPI
- macOS：使用 Keychain
- Linux：使用 libsecret
多进程架构：
- 主进程和渲染进程分离
- 安全的 IPC 通信机制
- 令牌的跨进程共享方案
离线能力：
- 网络中断时的处理策略
- 本地缓存和同步机制
- 重新连接时的鉴权流程
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 主流鉴权方案深度解析
2.1 方案一：连接后消息鉴权
2.1.1 实现原理
这种方案将鉴权过程分为两个阶段：
- 先建立 WebSocket 连接
- 连接成功后立即发送包含鉴权信息的消息
典型的消息格式如下：
json复制{
"action": "auth",
"token": "eyJhbGciOiJIUzI1NiIs...",
"timestamp": 1630000000
}