JWT令牌在服务端与客户端的验证校验相关技术疑问

基础调用流程 #

• A（客户端）-> B（API服务端）：客户端通过HTTPS（TLS加密）发送包含用户名和密码的请求
• B：服务端对客户端进行身份认证
• B -> A：服务端返回JWT令牌（非对称加密场景下，头部为{alg:RS256, typ:JWT}，添加声明后，对头部+载荷哈希，用服务端私钥签名生成签名）
• A：客户端接收令牌

疑问1：客户端是否需要验证收到的令牌？非对称/对称加密场景下分别需要什么密钥？ #

• 客户端建议验证令牌，尤其是高安全要求的场景，避免接收伪造或被篡改的令牌。
• 非对称加密（如RS256）场景：客户端需要服务端的公钥，用公钥验证签名合法性，确认令牌确实由目标服务端签发且未被篡改。
• 对称加密（如HS256）场景：客户端需要和服务端共享的密钥，用该密钥重新计算签名并与令牌内的签名比对，以此验证令牌合法性。

疑问2：非对称加密场景下，客户端发起API调用时如何使用令牌？ #

直接将收到的原令牌放入Authorization头部（格式通常为Bearer <token>）即可，不需要用自身私钥重新签名。
JWT的标准逻辑是服务端用私钥签名，客户端持有令牌，后续调用时服务端用公钥验证签名，客户端额外签名会增加不必要的复杂度，也不符合JWT的常规使用流程。

疑问3：服务端收到客户端的令牌后如何处理？多客户端场景下的公钥管理？ #

• 若客户端直接使用原令牌：服务端必须用自己的公钥验证签名（绝对不能只用字符串比对），同时校验令牌中的核心声明（比如过期时间exp、受众aud、签发者iss等）。字符串比对完全不可靠，因为合法令牌也可能因刷新、声明更新等产生变化。
• 若客户端用自身私钥签名令牌：这属于双向认证场景，服务端需要该客户端对应的公钥来验证签名。如果对接多个客户端，服务端需要存储每个客户端的公钥（或通过密钥管理服务动态获取），这种模式多用于高安全要求的服务间通信，而非普通客户端-服务端交互。

关于对称加密场景的令牌泄露风险 #

确实，对称加密下令牌一旦泄露，攻击者可以直接用该令牌发起请求，因为服务端无法区分请求来自合法客户端还是攻击者。这也是高安全场景更推荐非对称加密的原因：即使令牌泄露，攻击者没有服务端私钥就无法伪造新令牌，服务端还可以通过令牌黑名单、短有效期、IP绑定等手段进一步降低风险。
大部分示例采用对称加密是因为实现简单（无需管理公钥/私钥对），适合快速开发或低安全要求的场景，但生产环境尤其是涉及敏感数据的场景，建议优先选择非对称加密，或结合令牌刷新、短有效期等机制降低泄露风险。

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