同一应用的不同Token发行方不应共用签名密钥的安全原因有哪些

• 泄露影响隔离要求：Authorization Code Flow面向用户身份认证场景，签发的令牌代表用户授权权限，对应发行方通常有公网访问入口，攻击面更大；Client Credentials Flow面向服务间调用场景，签发的令牌通常持有应用级高权限，对应发行方一般部署在内网安全域。二者共享密钥的情况下，任意一方密钥泄露都会导致攻击者可同时伪造两种令牌，直接获得全场景的权限伪造能力，影响范围放大数倍。密钥隔离后可将泄露后的损失控制在单个场景内，避免风险跨场景传导。
• 规避校验逻辑缺陷风险：即使JWT标准提供了iss（发行方）、aud（受众）等声明用于身份校验，实际工程中仍普遍存在校验逻辑疏漏，比如仅验证签名有效性、未严格校验发行方声明的情况。共享密钥时，攻击者可直接篡改合法令牌的声明字段，冒充另一类令牌绕过权限校验；即使严格校验声明，密钥泄露后攻击者仍可构造完全符合声明规则的伪造令牌，校验逻辑完全失效。
• 密钥生命周期管理的必要性：两个发行方的运维场景、密钥轮换频率要求完全不同：面向公网的用户认证发行方通常需要高频轮换密钥降低泄露风险，内网的客户端凭据发行方密钥轮换频率更低。共享密钥要求双方必须严格同步密钥轮换节奏，极易出现配置不同步导致的合法令牌验签失败问题，提升运维故障概率。

即使两个发行方仅为同一应用签发令牌，也不能作为共享密钥的理由：两种令牌代表的权限主体完全不同，用户令牌代表自然人的授权范围，客户端令牌代表应用本身的后台操作权限，属于两类完全独立的安全凭证，必须从签名密钥层面做隔离。

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