合作方要求客户端生成JWT调用接口，该方案是否合规有何问题？

该JWT使用流程完全不符合JWT设计规范（RFC 7519）与行业通用实践，属于典型的JWT滥用场景，存在极高安全风险，绝对不能落地。

• 密钥泄露直接导致认证体系完全击穿：JWT签名密钥是最高级别的敏感凭证，规范要求必须全程存储在服务端可信环境，禁止下发到任何客户端侧。一旦客户端拿到密钥，任何可以接触到客户端的人员（包括普通用户、攻击者）都可以随意篡改JWT payload中的身份、权限、有效期等字段，自行伪造出100%能通过合作方校验的合法凭证，整个认证机制等于完全作废。
• 完全违背JWT的核心设计定位：JWT的设计逻辑是「可信身份签发方（仅服务端）在完成用户身份校验后统一签发凭证，客户端仅作为持有者传输凭证，无签发、修改权限」。该方案直接将签发权下放给不可信的客户端，JWT本身的价值完全不存在，纯粹是多此一举的冗余设计，直接用普通请求签名的成本比这低得多。
• 缺失全生命周期的凭证管控能力：常规JWT流程中，服务端签发时可以固定凭证的有效期、权限范围、签发主体等声明，后续也可以通过黑名单机制主动作废风险凭证。客户端自行签发的模式下，合作方完全无法管控JWT的生成逻辑，客户端可以无限生成永久有效、任意权限的凭证，后续如果要收缩权限、更换密钥的成本极高，只要密钥未更换，已泄露的客户端永远可以生成合法凭证。
• 完全缺失安全审计与溯源能力：正常JWT流程中，所有凭证都由服务端统一签发，可留存完整的签发日志，出现安全问题时可以快速追溯凭证的签发时间、关联用户、签发场景。客户端自行签发的模式下，完全无法区分收到的JWT是合法客户端生成的还是攻击者用泄露的密钥伪造的，出安全事故后没有任何溯源排查的依据。

如果合作方不想单独开发JWT签发接口，可以采用以下更安全的交互逻辑：

• 签名密钥仅保存在双方的服务端可信环境，绝对不下发到前端
• 你方客户端的请求先打到你方内部服务端，你方服务端完成用户身份校验后，用密钥生成合法的JWT或请求签名，再将请求转发到合作方的API端点

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