API Key 与客户端证书怎么选
API Key 是一个长期共享秘密：接入方把它放在请求头里，服务端查表比对。实现简单、几乎零门槛，但它表达的身份很弱——谁拿到谁就是那个应用，没有有效期概念，轮换要靠人工协调。mTLS 客户端证书则把身份写进证书主体，具备明确起止时间、可被 CRL/OCSP 吊销、可在握手中验证持有私钥，适合服务间强认证。选型的分水岭通常是：对手方是否可控、是否需要精细的吊销能力、以及合规模板里有没有明确要求。
基本信息
| API Key 优点 | 接入成本低、调试方便、适合对内部系统与开放平台 |
|---|---|
| API Key 缺点 | 长期有效、身份弱、轮换与吊销依赖平台表 |
| mTLS 优点 | 身份绑定主体、有有效期、支持吊销、握手即验证 |
| mTLS 成本 | 需要 PKI、证书分发与续期流程 |
| 传输规范 | API Key 应放请求头，不放 URL 查询参数 |
| 组合做法 | 短期凭证 + mTLS 或签名，兼顾强度与可运维性 |
典型使用场景
- 开放平台接入：给第三方发放 API Key，配合限流与用量统计。
- 服务间调用：核心链路上使用 mTLS，避免共享秘密扩散。
- 合规改造：监管要求双向认证时把 API Key 方案替换为证书方案。
- 临时联调：发放短期 Key 而非长期静态凭据。
- 分层设计：外部用 API Key 识别租户，内部用 mTLS 保证链路可信。
对比维度
| 维度 | API Key | 客户端证书（mTLS） |
|---|---|---|
| 身份表达 | 标识应用或账号，绑定弱 | 证书主体字段，可绑定组织与设备 |
| 有效期 | 通常长期有效 | 有明确起止时间 |
| 吊销能力 | 依赖平台名单与轮换 | CRL/OCSP 传播或替换证书 |
| 部署成本 | 低 | 需要 PKI 与分发流程 |
| 泄露后果 | 拿到即可冒充 | 缺少私钥无法完成握手 |
| 适用场景 | 对外开放接口、内部轻量调用 | 服务间强认证、合规链路 |
mTLS 连通性探测
mTLS 连通性探测
openssl s_client -connect api.example.com:443 -servername api.example.com \
-cert client.pem -key client.key -CAfile ca.pem </dev/null >/dev/null && echo mTLS_OK
# 验证服务端是否真的要求客户端证书：不带 -cert 时应握手失败
# curl --cert client.pem --key client.key --cacert ca.pem https://api.example.com/healthAPI Key 应通过请求头传输并配合限流与轮换；放在 URL 查询参数里会进入访问日志、浏览器历史与代理缓存，泄露面成倍扩大。
两种方案都不解决「调用方权限过大」的问题：凭据强度与授权范围是两条独立的线，凭据再强也不能省掉最小权限设计。