ApiGo 5.2.0 面世，本次版本的改动集中在一件事上：接口的准入规则。这个工具原本承担的工作没有变化，仍然是打通 ERP、CRM 等企业既有系统里的数据，把它们变成标准化 REST 接口与 MCP 工具，让 AI 智能体能处在可控范围内读取。新版本此前已有的 AppKey 认证、签名认证仍然保留，在此基础上又增加了两类企业内部更常见的身份鉴别方案。
新增 OAuth2 客户端凭证，适用于服务端之间的相互调用
依据源文说明，这个版本替代旧有签名模式的第一种选择是 OAuth2 客户端凭证流程，面向的场景包括智能体、后端服务以及定时任务之间的相互调用。调用一方凭手上已有的 AppKey 与 AppSecret，向授权端点申请一枚有效期较短的 access token，之后的每一次请求只要附带 Bearer token 即可，不需要再自行实现 HMAC 签名，各种语言的 OAuth2 官方库都可以直接投入使用。REST 接口和 MCP 入口这两条通道都支持这套方式。
在落地细节上有几处取舍。其一是没有另建一套凭据体系，client_id 直接对应 AppKey，client_secret 直接对应 AppSecret。其二是对令牌的签发来源做了限制，跨环境签发或由其他系统签发的、具有相同 kid 的 token 会被拒之门外。其三是服务端会话存放在 Redis 中，只要删掉对应 key，令牌即刻失效。其四是在信创环境下，签发算法可以切换为 SM2 国密算法。
企业 IdP JWT：复用既有统一身份，平台不掌握企业密钥
另一种方式是接受企业 IdP 签发的 JWT。已经部署 Keycloak、Azure AD、Okta、Authing 的团队，可以直接用本单位身份提供方出具的 token 请求 ApiGo，不需要在平台内部再维持一套并行账号。据原文所述，平台一侧只保留 IdP 的 JWKS 公钥，不会接触到企业那边的 client_secret，同时也不对外提供代为换取 token 的代理接口。
两种路径的差别体现在多个维度上。在 token 由谁签发这一点上，平台 OAuth2 走的是 ApiGo 网关的 /oauth2/token，企业 IdP JWT 则由企业自己的身份系统出具。调用方凭证方面，前者使用 AppKey 与 AppSecret，后者使用 IdP 的 client credentials 或者用户授权。平台是否保管密钥也截然不同：OAuth2 模式下 AppSecret 留在平台，JWT 模式下平台只是存了 IdP 公钥。应用身份识别上，前者依据 token 内部的 appKey，后者依据绑定的 (IdP, subject) 组合。适用对象也被区分开来，平台 OAuth2 适合平台内新建立的服务间调用，企业 IdP JWT 更适合已经具备统一身份体系的组织。
回答读者最关心的问题
谁签发令牌？来自平台一侧的走 ApiGo 网关的 /oauth2/token 端点；来自企业一侧的由企业 IdP 签发。
分别使用什么凭据？OAuth2 客户端凭证用 AppKey / AppSecret；IdP JWT 用企业 IdP 的 client credentials 或用户授权结果。
平台会保管企业密钥吗？平台侧 OAuth2 持有 AppSecret；IdP JWT 情况下平台只留公钥。
新方式会影响 MCP 入口吗？不区分，REST 接口与 MCP 入口对这两类认证均可用。
凭证吊销怎么做？OAuth2 流程的服务端会话存在 Redis，删除对应 key 即为即时吊销。
需要注意的是，原文中有两处信息标注：一则内容表明有关总结片段由社区平台借助 AI 大模型生成；末尾则声明本次新闻不允许未经授权转载，违者将依法追究责任，授权事宜可联系 oscbianjioschina.cn 这一邮箱地址。
小结：ApiGo 5.2.0 的认证扩展体现了企业在接入时可复刻现有身份基础设施的思路：要自主可控、账号自成体系的可选 OAuth2 客户端凭证，已经在用 Keycloak、Azure AD 之类身份平台的单位不妨选 IdP JWT，一条密钥留在平台内，一条仅需信任外部公钥；而三种处理方式的入口都同时覆盖 REST 与 MCP 两层。