基于api_key与api_secret的SDK鉴权原理及防滥用机制

你猜测的“类似用户名密码组合换访问令牌”只覆盖了一部分场景，行业内没有强制统一的规范，但绝大多数商用SDK的鉴权逻辑都跑不出下面两类模式，核心逻辑非常直白，没有什么黑科技：

客户端类SDK（安卓/iOS/前端JS这类跑在用户设备上的SDK） #

• api_key就是纯公开的应用身份标识，相当于服务端给每个注册应用发的唯一ID，所有请求都会明文携带这个参数。服务端收到请求第一步就会校验这个key是否存在、对应哪个应用、有没有被封禁、开通了哪些接口权限，直接过滤掉无效请求。
• api_secret是用来做请求签名的密钥，绝对不会明文出现在网络请求里。毕竟客户端的流量很容易被抓包，要是把secret直接传出去，等于谁都能伪造你的应用请求。
  实际运行时，SDK每发起一次请求，都会先把请求的全部参数——包括api_key、当前时间戳、随机生成的防重放nonce字符串、请求路径、请求体内容——按照和服务端预先约定的规则排序拼接成字符串，再用api_secret作为密钥，通过HMAC-SHA256这类不可逆哈希算法算出一个签名值，把这个签名附在请求里发给服务端。
  服务端拿到请求后，先根据传过来的api_key查出数据库里存的对应secret，用完全一致的规则重新计算一次签名，和请求带的签名做比对：签名一致就说明请求是持有合法secret的合法客户端发的，传输过程中参数也没被篡改；不一致直接返回鉴权失败。
• 你提到的换临时令牌的优化逻辑确实非常普遍：如果每次请求都走全量签名校验，不管是客户端算签名还是服务端验签都有性能开销，所以大部分SDK会在init初始化阶段，按照上面的签名规则给鉴权接口发一次校验请求，服务端验证通过后返回一个有时效的临时token（常见有效期是2小时到7天不等），存在SDK本地。后续普通业务请求只需要带api_key和这个临时token就能完成鉴权，不用每次都用secret算签名，等token过期了再用secret重新签名换发新的即可。

这里要纠正一个常见误区：客户端SDK里的api_secret做不到绝对保密，毕竟安卓安装包可以被反编译、前端JS代码可以直接看到，所以服务端一般会给客户端类型的secret配严格的接口权限限制、请求频率限制，就算secret被泄露，影响范围也可控。

服务端类SDK（跑在开发者自有服务器上的SDK） #

这类SDK的运行环境是开发者自己可控的服务器，不存在secret被普通用户拿到的风险，逻辑会更简单：

• 部分轻量SDK会直接让每次请求都携带api_key和用api_secret生成的签名，服务端验签通过就放行。
• 更多SDK的逻辑和你猜测的基本一致：初始化时用api_key+api_secret通过类OAuth客户端模式的流程，和服务端交互换一个有有效期的访问令牌，后续所有请求只带这个令牌就能完成鉴权，和普通登录态的逻辑没有本质区别。这类场景下的secret一般对应全量接口权限，因为不会暴露到公网侧，服务端也不会加过多的权限限制。

关于开源实现参考 #

不需要专门找讲解SDK鉴权原理的专项资料，所有主流开放平台的开源SDK鉴权模块逻辑都是通用的：不管是云厂商的服务端SDK，还是各类SaaS服务的移动端开源SDK，鉴权部分的代码基本都是上面说的逻辑，拆开来读一遍就能完全搞懂，不存在什么未公开的私有协议。
核心逻辑本质就是三个环节：用api_key做身份识别、用api_secret做签名校验防伪造防篡改、可选下发临时令牌优化鉴权性能，整个流程没有复杂的特殊设计。

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