Spring Boot：跨服务器生成JWT并实现认证方案咨询

核心逻辑 #

你的场景核心是跨节点的JWT信任传递：首服务器作为JWT签发方，其他节点作为验证方，同时结合本地数据库的用户授权校验，确保请求是由首服务器合法转发的用户发起的。关键在于所有节点共享JWT的验证规则，同时通过JWT的字段约束确保签发来源可信。

具体实现步骤 #

1. 统一JWT签名规则 #

所有服务器必须遵循相同的签名验证逻辑，分两种常用方案：

• 对称加密方案（适合内部可信集群）：所有节点共享同一个签名密钥（比如your-shared-secret-key），首服务器用该密钥签名JWT，其他节点用同一密钥验证签名合法性。
• 非对称加密方案（适合跨信任域场景）：首服务器持有RSA/ECC私钥，用于签名JWT；其他所有服务器存储对应的公钥，仅用于验证签名，无需接触私钥，安全性更高。

2. 首服务器生成JWT并重定向 #

当用户首次连接首服务器后，执行以下操作：

• 生成JWT的Payload（负载），必须包含以下核心字段：
  • sub：用户唯一标识（比如用户ID，不要存明文密码）
  • iss：签发服务器的唯一标识（比如首服务器的域名/ID，如auth-node-01）
  • exp：JWT过期时间（建议设为5-15分钟的短有效期，降低被盗用风险）
  • 可选字段：aud（受众，即目标服务器标识，如api-node-03），用于限制JWT仅能被指定服务器使用
• 使用统一规则的密钥签名JWT，生成最终的令牌字符串
• 将JWT通过安全方式传递给目标服务器：
  • 优先选择HttpOnly、Secure、SameSite=Strict的Cookie（避免XSS攻击）
  • 若用URL参数传递，必须确保使用HTTPS，同时避免服务器日志记录完整的JWT

3. 目标服务器的认证与授权流程 #

目标服务器接收重定向请求后，按以下步骤处理：

1. 提取并验证JWT合法性：
   • 从Cookie/URL参数中取出JWT
   • 验证签名是否有效（用共享密钥或公钥）
   • 检查exp字段，确认JWT未过期
   • 验证iss字段是否为预设的首服务器标识，确保JWT确实由合法签发方生成
   • 若有aud字段，验证是否匹配当前服务器的标识，防止JWT被滥用在其他节点
2. 本地数据库授权校验：
   • 从JWT的sub字段获取用户ID，查询本地数据库的用户信息
   • 验证用户是否存在，以及是否具备访问当前API的权限（如果需要细粒度权限控制）
3. 完成认证：
   • 验证通过后，可选择生成当前服务器的会话JWT（可选，用于后续API请求），或者直接允许用户访问目标API
   • 验证失败则返回401/403错误，拒绝访问

4. 确保用户数据一致性 #

所有服务器的本地数据库必须同步用户核心数据（ID、权限等），可通过以下方式实现：

• 采用主从复制架构，首服务器的数据库为主库，其他节点数据库为从库，实时同步用户数据
• 使用分布式数据库（如MongoDB集群、MySQL分片），确保所有节点能查询到统一的用户信息

关键注意事项 #

• 传输安全：全程必须使用HTTPS，防止JWT在传输过程中被窃取
• 密钥管理：对称密钥需定期轮换，非对称私钥必须严格保密，仅在首服务器存储，公钥可安全分发至所有验证节点
• 避免敏感信息：JWT的Payload是Base64编码（可解码），绝对不能存放密码、手机号等敏感数据，仅保留用户ID、签发者等非敏感标识
• 过期时间控制：短有效期JWT配合刷新令牌（若需要长期会话），刷新令牌需存储在服务器端并严格校验
• 日志安全：避免在服务器日志中记录完整的JWT，防止泄露

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