防止Authorization-Code-Flow Jwt调用仅后端互访服务的最佳实践

核心思路是从令牌签发源头加明确标识、资源端多层校验兜底，不要靠模糊特征判断，具体落地可以按下面几层做，从强到弱层层设防：

• 优先使用JWT标准声明做流类型识别
  合规实现的OAuth2授权服务签发的JWT，本身会自带标准的gty（Grant Type）声明，字段值就是签发令牌所用的授权流：授权码流对应的值是authorization_code，客户端凭证流对应的值是client_credentials，不需要额外自定义字段，直接用这个标准字段做判断依据即可，避免自定义字段带来的兼容问题。
• 纯后端服务侧加硬校验规则
  所有仅支持后端互访的服务，在鉴权中间件最前置的位置加校验：解析JWT后首先判断gty字段值，只要不是client_credentials直接返回403拒绝，不管令牌携带了什么scope、什么权限声明，都不进入后续的权限判断流程，从入口直接拦截授权码流的令牌。
• 用受众（aud）声明做逻辑隔离
  不要给两类令牌签发相同的aud值：给客户端凭证流签发的令牌，aud固定为纯后端服务专属的受众标识，比如internal-api；给授权码流签发的面向用户的令牌，aud仅配置对外暴露的服务标识，比如public-api。纯后端服务校验令牌时，首先校验aud必须匹配自身专属标识，不匹配直接拒绝，这是OAuth2标准定义的令牌使用范围控制能力，适配性最好。
• 权限scope做前缀隔离
  后端内部接口所需的权限scope统一加专属前缀，比如internal:开头，授权服务器在签发授权码流的令牌时，从规则上禁止签发任何带internal:前缀的scope，从签发源头就避免用户令牌拿到内部接口的访问权限，就算前面的流校验、aud校验出现配置疏漏，也能靠权限校验兜底拦住请求。

避坑提醒：不要靠「令牌里有没有用户ID」「过期时间长短」这类非确定性的特征区分两类令牌，后续授权流程迭代（比如新增其他授权流、调整令牌有效期策略）很容易改变这些特征，导致鉴权规则失效。所有判断依据必须是签发时强制写入、签名保护不可篡改的明确声明字段。

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