多站点共享SignalR Hub的安全防护方案咨询

针对你的场景——多站点共享SignalR Hub、用JWT识别用户但Token仅存服务器端、需关联用户与连接且不能使用机对机Token，可采用以下几种方案保障安全：

服务器端Token转发+Cookie认证联动 #

1. 流程逻辑：用户通过站点的Cookie完成登录后，站点以自身服务身份向IdentityServer4发起服务器端请求，获取包含该用户主体信息的JWT（此请求完全在服务器间进行，用户浏览器无感知）。
2. SignalR连接处理：当用户触发SignalR连接请求时，站点先验证用户Cookie的有效性，确认身份后将服务器端获取的JWT通过服务器端代理转发给SignalR Hub，而非通过浏览器传递Token。
3. Hub验证：SignalR Hub接收到Token后，直接与IdentityServer4进行合法性校验，校验通过后提取用户主体信息，建立连接与用户的关联关系。
4. 安全注意点：服务器间通信必须使用HTTPS加密；站点需严格校验Cookie的有效性，仅为已登录用户发起Token请求；设置JWT的短生命周期，降低泄露风险。

基于共享会话存储的身份映射 #

1. 核心思路：利用各站点与SignalR Hub共享的分布式会话存储（如Redis），通过会话标识关联用户身份与SignalR连接。
2. 流程逻辑：
   • 用户登录站点后，站点生成唯一的高熵会话标识，将该标识与用户主体信息绑定后存入共享会话存储，同时将会话标识写入用户浏览器的Cookie（仅存标识，不存敏感信息）。
   • 用户发起SignalR连接请求时，站点先验证Cookie中的会话标识有效性，确认后将该会话标识通过服务器端传递给SignalR Hub。
   • Hub根据会话标识从共享存储中读取对应的用户主体信息，完成连接与用户的关联。
3. 安全注意点：会话标识需使用足够长度的随机字符串，避免被猜测；设置会话标识的短过期时间，并支持自动刷新；共享存储需配置严格的访问权限，防止未授权读取。

服务器端托管的临时用户级Token #

1. 方案逻辑：IdentityServer4生成绑定特定用户主体的短生命周期临时Token，该Token全程仅在服务器端流转，不会触及用户浏览器。
2. 流程步骤：
   • 用户登录站点后，站点向IdentityServer4申请该用户专属的临时Token，将Token与用户Cookie关联后存储在服务器端（如Redis）。
   • 建立SignalR连接时，站点从服务器存储中取出对应Token，通过代理转发给Hub；Token过期前，站点自动向IdentityServer4申请新Token，用户无感知。
   • Hub验证Token合法性后，提取用户主体信息完成关联。
3. 安全优势：Token仅在服务器间传递，完全避免前端泄露风险；短生命周期设计进一步降低了Token泄露后的危害范围；Token与用户强绑定，无法被其他用户冒用。

内容的提问来源于stack exchange，提问作者Cristian Zambiasi