前言
在日常开发中难免会遇到对接三方平台，比如文件的云存储、短信通道、认证等，在调用这些三方接口时往往需要进行先认证，认证完成之后才能够进行正常的业务处理。
在认证的过程中，往往会提供appid、appkey、appsecret三对key-value的数据。本篇文章就带大家深入了解一下这三组认证所需数据的功能及生成。
先简单概况一下：app_id，应用的唯一标识；app_key，公匙（相当于账号）；app_secret，私匙（相当于密码）。
app_id参数
app_id通常情况下指的是一个用户的账号，类似在三方支付系统中给商户开的customer_no，表示一个企业或个人的账号。
该账号通常跟开通的商户实体所一一对应。通过该参数平台能找到你是谁。在接口调用的过程中很少直接使用app_id，一般会配合秘钥使用。
app_key和app_secret
现在有了统一的app_id，此时如果针对同一个业务要划分不同的权限，比如同一功能，某些场景需要只读权限，某些场景需要读写权限。这样提供一个app_id和对应的秘钥就没办法满足需求。
此时就需要引入针对权限进行账号分配，通常使用app_key和app_secret。
以OSS存储为例，在后台管理界面对存储的文件拥有删除的权限，而对于用户端可能只需要读或写的权限就行。那么此时，就可以生成两对儿app_key和app_secret。一个用于删除，一个用于读写，达到权限的细粒度划分。
app_key和app_secret成对出现
通常情况下，app_key和app_secret用在通信的首次认证当中，认证完成平台会返回一个token（通常拥有失效时间），后续的交互通过该token即可。
那么为什么app_key和app_secret会成对出现呢？我们可以这样理解，app_key用来标记调用接口的方享受哪些权限，而app_secret用来表示你真的拥有这个权限。其实这里app_key与app_id功能相似。当系统只有一个用户并且只有一套权限时，它们两者是等价的。
不同使用方式
第一种场景：通常用于开放性接口，像地图api，会省去app_id和app_key，此时相当于三者相等，合而为一。这种模式下，带上app_id的目的仅仅是统计某一个用户调用接口的次数而已了。
第二种场景：只会提供app_key和app_secret，在客户端根据一定的算法生成认证的token，调用接口时带上该token就可以了。像七牛云的接口调用就使用的这种模式。
第三种场景：调用接口时同时携带app_key和app_secret传递到服务器，服务器返回对应的token，后续业务接口的调用通过token进行校验。
第四种场景：上面的验证方式相对宽松，如果token被窃取，就可以伪造报文进行请求。还有一种比较严格的就方式就是每次请求的参数都进行签名（MD5或SHA1等）处理，而app_secret不会通过网络传输，只会存储于商户端和服务器端。
校验的方式通常是讲核心字段按照key的升序进行排列，组成key=value&key=value的形式，最后再加上app_secret的字符串，然后使用签名算法，计算出一个sign值。请求时，将除app_secret以外的原业务报文和sign值传递给服务，服务器接收到之后，按照同样的方式进行延签。签名一致则说明报文在传输过程中未被篡改。像腾讯云就使用此种模式。
