OAuth2.0服务端client_secret_jwt认证时如何确定解析JWT的对应密钥

1、RFC规范相关说明 #

RFC7523 2.2节对client_secret_jwt的JWT结构有明确强制要求，不存在未覆盖该问题的情况：

用于客户端认证的JWT必须携带iss（签发者）声明，该声明的取值必须为客户端注册获得的client_id；同时sub（主体）声明取值也必须和client_id一致。

另外JWT本身的结构特性决定了，Header和Payload是公开的Base64URL编码内容，不需要密钥即可直接解码读取。IDP收到请求后可以先解码JWT的Payload部分，提取iss字段拿到client_id，再查询数据库获取对应client_secret做签名校验即可，不需要请求额外携带client_id参数。

2、是否需要自行实现逻辑 #

标准流程下不需要自行实现额外扩展逻辑，严格遵循RFC规范要求即可：

• 要求所有接入的客户端生成JWT时必须按照规范填充iss为自身client_id
• IDP侧先无密钥解码Payload拿client_id，再查密钥做验签
  只有在需要兼容不遵守规范的特殊客户端时，才需要自行做逻辑扩展。

3、遍历所有客户端密钥方案的可行性 #

该方案完全不可行，存在明显缺陷：

• 性能问题：如果IDP接入的客户端量级超过千级，每次请求遍历全量客户端密钥会带来极高的查询延迟和数据库压力，完全无法满足生产环境可用性要求
• 安全问题：该方案会带来严重的安全风险，攻击者可构造请求触发全量遍历，很容易发起拒绝服务攻击打垮IDP服务；同时全量匹配也会提升密钥碰撞、暴力破解的风险

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