OAuth2/OIDC场景下，如何从服务端视角识别客户端应用？

核心需求 #

从服务端视角，准确识别调用Web服务的客户应用（而非用户），用于变更通知、审计，且需规避以下不可靠方案：用户账号、源IP、令牌中的azp/client_id（因令牌可被下游合法转发，且azp实现不统一）

问题1：OAuth2/OIDC是否为该场景设计？ #

OAuth2和OIDC原生支持客户端标识（通过client_id），但未针对“令牌被下游非请求方转发使用”的场景设计。

• 协议默认令牌由获取它的客户端直接使用，azp（授权方）声明指向的是最初获取令牌的客户端，而非当前发起请求的客户端。
• 虽然OIDC规范定义了azp，但确实存在部分厂商实现不统一的情况，且无法覆盖令牌转发后的调用方识别需求。
  所以你的场景属于协议原生能力的盲区，并非你遗漏了什么。

问题2：是否需要自定义逻辑，还是有标准方案？ #

优先选择标准方案，而非自定义逻辑，推荐以下两种：

• Mutual TLS (mTLS)：要求每个客户端使用唯一的客户端证书发起请求，服务端通过证书的CN或SAN字段识别客户端。该方案符合标准，且可与OAuth2/OIDC集成（Keycloak支持mTLS客户端认证），能有效防止令牌转发后的身份冒充，因为证书与客户端绑定，无法轻易转发。
• HTTP Signatures (RFC 9421)：在请求头中添加客户端签名（使用客户端私钥），同时携带client_id，服务端通过公钥验证签名并确认客户端身份。该方案支持跨TLS场景，且是标准化的请求身份验证方式。
  如果以上标准方案落地成本过高，可实现自定义签名请求头（需确保签名不可伪造），但长期来看标准方案更具可维护性。

问题3：依赖API密钥是否可行？ #

API密钥方案可行，但仅适合无令牌转发的简单M2M场景，且存在明显弊端：

• 失去OAuth2/OIDC的核心优势：无法实现短期令牌、细粒度权限控制、令牌吊销、统一身份管理等能力。
• 无法解决令牌转发场景的问题：若API密钥被下游获取并转发，服务端仍无法识别真实调用方，和azp的问题本质一致。
  因此不推荐在已有OAuth2/OIDC体系下切换到API密钥，除非你的场景完全不存在令牌转发，且对OAuth2的优势无需求。

内容的提问来源于stack exchange，提问作者Léo