是否必须始终使用生成JWT的服务器密钥验证JWT有效性？

你的核心误解：JWT验证必须依赖签名密钥 #

首先明确：任何要验证JWT签名有效性的服务，必须持有生成该JWT时使用的签名密钥（或对应的公钥，非对称加密场景），否则根本无法判断签名是否合法。你提到的“无需知晓密钥就能验证”是错误认知——如果某个服务没用到正确密钥就声称“验证通过”，那它根本没做真正的签名校验，只是解析了JWT的明文部分（Header和Payload本来就是Base64编码，任何人都能解码）。

如何防范恶意伪造JWT？ #

针对恶意用户用自定义密钥签假JWT、篡改声明的情况，核心解决办法就是：

• 所有接收JWT的服务，必须使用与身份服务一致的密钥（或公钥）完成签名验证
• 验证流程必须包含两步：
  1. 用正确密钥对JWT的签名部分校验，确认Header和Payload未被篡改，且确实是合法身份服务签发
  2. 签名校验通过后，再提取Payload里的声明信息使用

如果接收服务跳过第一步签名校验直接解析Payload，必然会被恶意伪造的JWT欺骗——就像你测试的那样，用自己的密钥签假admin的JWT，服务没验签名就直接采信了。

不同场景下的密钥管理方式 #

根据加密算法类型，密钥使用方式分为两种：

• 对称加密（如HS256）：身份服务和所有接收JWT的API服务，必须共享同一个密钥。该密钥要严格保密，不能泄露给外部方，也不能硬编码到代码中，需通过环境变量、密钥管理服务（如AWS KMS、HashiCorp Vault）存储和获取。
• 非对称加密（如RS256）：身份服务用私钥签名JWT，所有接收服务只需持有对应的公钥验证签名。这种方式更安全，私钥仅在身份服务端保管，公钥可安全分发给各个API服务，无需担心泄露。

额外的安全校验步骤 #

除签名校验外，还要对JWT的声明做额外校验：

• 检查exp（过期时间），确保JWT未过期
• 检查iss（签发者），确认是信任的身份服务
• 检查aud（受众），确认JWT是发给当前服务的
• 检查nbf（生效时间），确保JWT已到生效时间

这些校验能进一步防止恶意使用过期或不符合场景的JWT。

内容的提问来源于stack exchange，提问作者Q-bertsuit