开放API平台都有的appid、appkey、appsecret分别是什么意思？
前言
在日常开发中难免会遇到对接三方平台，比如文件的云存储、短信通道、认证等，在调用这些三方接口时往往需要进行先认证，认证完成之后才能够进行正常的业务处理。
在认证的过程中，往往会提供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值传递给服务，服务器接收到之后，按照同样的方式进行延签。签名一致则说明报文在传输过程中未被篡改。像腾讯云就使用此种模式。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
