app_id, app_key, app_secret, 对于平台来说, 需要给你的 你的开发者账号分配对应的权限:
-
app_id是用来标记你的开发者账号的, 是你的用户id, 这个id 在数据库添加检索, 方便快速查找 -
app_key和app_secret是一对出现的账号, 同一个app_id可以对应多个app_key+app_secret, 这样 平台就可以分配你不一样的权限, 比如 app_key1 + app_secect1 只有只读权限 但是 app_key2+app_secret2 有读写权限.. 这样你就可以把对应的权限 放给不同的开发者. 其中权限的配置都是直接跟app_key做关联的,app_key也需要添加数据库检索, 方便快速查找 - 至于为什么 要有
app_key+app_secret这种成对出现的机制呢, 因为 要加密, 通常 在首次验证(类似登录场景) , 你需要用app_key(标记要申请的权限有哪些) +app_secret(密码, 表示你真的拥有这个权限) 来申请一个token, 就是我们经常用到的access_token, 之后的数据请求, 就直接提供access_token就可以验证权限了.
上述3点说的有点多哈, 不知道讲明白了没, 顺便再说一下简化的场景:
- 省去
app_id, 他默认每一个用户有且仅有一套权限配置, 所以直接将app_id=app_key, 然后外加一个app_secret就够了. - 省去
app_id和app_key, 相当于app_id=app_key=app_secret, 通常用于开放性接口的地方, 特别是很多地图类api 都采用这种模式, 这种模式下, 带上app_id的目的仅仅是统计 某一个用户调用接口的次数而已了.
AppID：应用的唯一标识
AppKey：公匙（相当于账号）
AppSecret：私匙（相当于密码）
token：令牌（过期失效）
使用方法
向第三方服务器请求授权时，带上
AppKey和AppSecret（需存在服务器端）第三方服务器验证
AppKey和AppSecret在DB中有无记录如果有，生成一串唯一的字符串（
token令牌），返回给服务器，服务器再返回给客户端客户端下次请求敏感数据时带上令牌
关于第一点，可以采用签名的方式发送，当应用服务端向第三方服务端发请求时，带上
AppKey、时间戳、随机数、签名，签名可以使用AppSecret+ 时间戳 + 随机数使用sha1生成，第三方服务端收到后，生成本地签名和收到的签名比对，如果一致，校验成功
