client_id;平台服务端要调用 Clink 接口时,还需要 client_secret。本页说明怎么申请、Clink 会登记什么,以及三种注册方式分别适用于哪种接入。取得凭据后,回到对应的接入文档继续:如何对接 MCP、如何对接 RESTful API或如何对接 Vault SDK。
选择注册方式
平台服务端调用
/platform/sessions、Portal API 或 Vault 时必须用 client_secret 换取平台 Token,所以 RESTful API 和 Vault SDK 只能使用 Pre-registration,平台 client 也不能通过 DCR 自行创建。CIMD 和 DCR 只适合自己开发 MCP Host、让每位用户直接完成标准 OAuth 授权的场景。
Pre-registration(推荐)
由 Clink 在目标环境为你登记 client 并签发凭据。Clink 为每个环境分别签发:Sandbox UAT(https://uat-api.clinkbill.com)和 Production(https://api.clinkbill.com)的凭据不能混用。
向 Clink 提供
- 应用名称、技术联系人和目标商户场景。
- Sandbox UAT 和 Production 的部署信息。
- 首次用户授权使用的固定 HTTPS
redirect_uri。MCP 和 RESTful API 需要;Vault SDK 不需要。 - 要使用的接入方式和能力,Clink 据此登记 Scope,见下表。
- 推荐:平台 RSA 公钥,见登记 RSA 公钥。
Clink 签发
同时接入 MCP 和 RESTful API 时只需要一个平台 client。Vault SDK 的凭据单独签发,不能和平台 client 混用。
自己开发 MCP Host、只需要 public client 时,也可以请 Clink 只登记
client_id、不签发 client_secret。这种 client 的授权方式与 CIMD、DCR 相同,见发起用户授权。
登记 RSA 公钥
如果希望支付凭证以加密的key / payload 返回,线下联系 Clink,为每个环境登记 PEM X.509 SubjectPublicKeyInfo 格式的 RSA 公钥(BEGIN PUBLIC KEY)。公钥登记和 client 登记是两个独立步骤。
- MCP 的
get_credential和 RESTful API 的POST /agent/platform/credential都使用这把公钥;Vault SDK 不需要。 - RESTful API 未登记公钥且服务端没有开启明文模式时,凭证接口返回
71211012(credential_public_key_not_configured)。生产环境建议登记。 - 私钥只保存在平台可信组件中,解密方式见加密凭证解密。
保存凭据
你的后端需要保存:CLINK_CLIENT_ID、CLINK_CLIENT_SECRET。同时接入 Vault SDK 时,另存一组 Vault 凭据。- 平台登记的精确
redirect_uri。 - RSA 私钥(如果登记了公钥)。
client_secret 和 RSA 私钥只能保存在可信服务端,不要放进浏览器代码、URL、日志、Agent 输入或普通业务消息。每个环境只使用一组平台凭据,所有用户共用;不要为每个用户或每次请求申请新的 client。
CIMD
仅适用于 MCP。适合能在自己的 HTTPS 域名下托管公开 JSON 文件的 MCP Host。托管文件,并把文件 URL 作为client_id:
- URL 使用 HTTPS,带路径,不带 query 和 fragment。
- 文件中的
client_id与文件 URL 完全一致。 - 直接返回 HTTP 200,
Content-Type为application/json;Clink 不会跟随跳转。 - 文件不超过 5 KB,不包含任何 Secret。
DCR
仅适用于 MCP。适合不能托管公开 HTTPS 文件,或 Host 只支持动态注册的场景。先读取{API_BASE_URL}/.well-known/oauth-authorization-server,只有返回 registration_endpoint 时才能使用 DCR:
client_id。Clink 不支持修改已注册的 client:需要调整 redirect URI 或 Scope 时,重新注册一个 client,用户也要用新的 client_id 重新授权。
CIMD 和 DCR 的共同规则
- 两者都是 public client,没有
client_secret,必须使用 Authorization Code + PKCE(S256)。 - 注册的 Scope 是之后每次授权请求的上限,超出会返回
invalid_scope,所以注册时要写全 Agent 可能用到的 Scope。 - 每个部署、租户或安装实例只注册一次,所有用户复用同一个
client_id。 - 没有
client_secret就不能调用/platform/sessions,取得client_id后需要自己发起用户授权,见下文。
发起用户授权
- 读取
{API_BASE_URL}/.well-known/oauth-protected-resource/mcp,从authorization_servers取得 issuer。 - 读取
{issuer}/.well-known/oauth-authorization-server,取得authorization_endpoint和token_endpoint。不要把端点写死在代码里。 - 为当前用户生成并临时保存
state和 PKCEcode_verifier,用 S256 计算code_challenge。 - 把用户重定向到
authorization_endpoint,参数全部 URL 编码:
client_id 换成你取得的 public client 值。之后按如何对接 MCP步骤 2 和步骤 3 配置 system prompt 和 MCP。遇到 403 insufficient_scope 时,从 WWW-Authenticate 响应头的 scope 参数读取所需 Scope,与已授予的 Scope 合并后让用户重新授权;合并结果不能超出注册的 Scope。