双独立应用共用同一JWT的架构设计与校验策略咨询

适配当前场景的落地架构 #

• 先划清两个应用的JWT权责边界：应用A作为唯一的Token签发源，承担登录校验、身份核验、用户域核心信息写入载荷、密钥轮换规则制定、Token吊销状态同步的全部职责；应用B作为纯Token消费端，完全不涉及签发逻辑，仅做身份校验与所需用户信息提取，绝不授予B签发侧的密钥操作权限。
• 提前约定标准化的JWT载荷规则：把B业务必须用到的用户信息（比如用户唯一ID、基础角色标签、账户状态）统一约定字段命名、数据结构、取值范围，避免A后续迭代调整字段格式导致B的业务逻辑失效；注意不要把不需要跨应用共享的敏感隐私信息（比如用户手机号、实名信息）塞进公共JWT载荷，确需使用时走单独的受控接口拉取，不要过度放大Token的泄露影响面。
• 做密钥的权限拆分：优先选用非对称加密算法（比如RS256）做JWT签发，A端保留可用于签发的私钥全量权限，给B端仅下发对应的验签公钥，从根源上避免B端的密钥被泄露后出现伪造Token的风险；如果因为历史原因必须用对称加密算法（比如HS256），要把密钥同步逻辑挪到加密的配置中心，定期做密钥轮换，禁止把密钥硬编码在应用代码仓库里。

关于独立JWT校验器的部署判断 #

核心结论：没有必要为两个应用单独重复开发、部署两套独立的JWT校验能力，核心是要避免校验规则出现不一致的问题

• 首先，JWT的基础校验流程（验签、校验过期时间exp、校验签发主体iss、校验受众aud）是完全标准化的，两个应用如果各自写一套校验代码，很容易出现规则偏差——比如A端校验时漏了iss字段的合法性校验，B端因为配置问题把aud字段设成了不存在的值，就会出现“A签发的Token在B端无法正常识别”的低级故障，排查成本极高。
• 分场景的落地选择：
  • 如果后续只会有A、B两个应用复用JWT，直接把标准化的校验逻辑封装成通用的SDK，两个应用都依赖同一个SDK做校验，不需要额外部署独立的校验服务，既能保证规则统一，也能把运维成本降到最低。
  • 如果后续会有更多业务应用复用这套JWT能力，或者两个应用的校验规则会出现差异化（比如B端需要额外校验用户是否拥有特定场景的操作权限），可以把校验能力抽成独立的轻量服务，所有应用的校验请求统一走这个服务，不用每个应用单独维护一套校验逻辑。
  • 如果已经有统一的入口网关，完全可以让所有访问B的请求先过网关做统一JWT校验，B端直接从网关注入的请求头里读取解析好的用户信息即可，连内嵌的校验逻辑都不需要开发。
• 必须避开的坑：任何场景下都不能把A端的私钥签发权限下放给B端，一旦B端出现安全漏洞，攻击者拿到签发权限后可以直接伪造任意用户的身份令牌，直接击穿整个用户域的安全体系。

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