如何通过API Gateway识别客户端？OAuth2双令牌架构下的身份传递困境

• 嵌入原客户端ID到网关的JWT自定义声明中
  协调授权服务器团队，允许网关在通过client_credentials模式请求token时，携带原客户端的client_id作为额外参数（比如请求体里添加original_client_id字段，或利用扩展的scope字段传递）。授权服务器在生成网关的JWT token时，将这个original_client_id写入到JWT的自定义声明（如org_client）或标准的azp（Authorized Party）字段中。
  你的API作为资源服务器，解析网关的JWT时直接读取该声明即可识别原客户端。此方案无需网关添加额外请求头，所有身份信息都在签名后的JWT内，符合安全要求；网关也无需维护多套token，仅需在每次请求时传递原客户端ID参数，开销可忽略。

• 采用OAuth2令牌交换（Token Exchange）规范
  让网关使用OAuth2令牌交换流程（RFC 8693）：客户端先从网关拿到token后，网关将该客户端token作为subject_token，向授权服务器发起令牌交换请求，申请用于访问你的API的token。授权服务器验证客户端token的有效性后，生成包含原客户端身份信息的新JWT token返回给网关。
  此方案遵循OAuth2标准，身份信息全程在签名令牌中传递，安全合规；网关仅需实现令牌交换的请求逻辑，无需维护多客户端的token池，符合网关团队的开销要求。

• 验证客户端token并提取身份嵌入网关token请求
  如果客户端从网关获取的token是JWT格式，网关可先验证该token的签名、过期时间等有效性（内部系统可共享密钥或使用统一的JWKS端点），提取出客户端的client_id。随后在向授权服务器请求自身的access token时，将该client_id作为自定义参数传递，授权服务器将其写入网关的JWT声明中。
  该方案同样保证身份信息在签名JWT内，无篡改风险；网关的JWT验证操作轻量，不会带来显著开销，且无需修改网关的核心token管理逻辑。

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