如何获取开放API接口平台的appid、appkey、appsecret？
- 内容介绍
- 文章标签
- 相关推荐
本文共计4089个文字，预计阅读时间需要17分钟。
1. 什么是appid、appkey、appsecret？ - AppID：应用的唯一标识符。 - AppKey：官方（相对账户）。 - AppSecret：私钥（相对密码）。
2. token（过期失效）： - 令牌，用于身份验证，有效期内有效。
3. app_id： - 用于标记你的开发者账号。
一、什么是appid、appkey、appsecret
AppID：应用的唯一标识。 AppKey：公匙（相当于账号）。 AppSecret：私匙（相当于密码）
token：令牌（过期失效）
-
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 就可以验证权限了。
简化的场景
- 1、省去 app_id，他默认每一个用户有且仅有一套权限配置，所以直接将 app_id = app_key，然后外加一个app_secret就够了。
- 2、省去app_id 和 app_key，相当于 app_id = app_key = app_secret，通常用于开放性接口的地方，特别是很多地图类api 都采用这种模式，这种模式下，带上app_id 的目的仅仅是统计 某一个用户调用接口的次数而已了。
使用方法
- 1、向第三方服务器请求授权时，带上AppKey和AppSecret（需存在服务器端）
- 2、第三方服务器验证AppKey和AppSecret在DB中有无记录
- 3、如果有，生成一串唯一的字符串（token令牌），返回给服务器，服务器再返回给客户端
- 4、客户端下次请求敏感数据时带上令牌
二、云服务AppId或AppKey和AppSecret生成策略
App key简称API接口验证序号，是用于验证API接入合法性的。接入哪个网站的API接口，就需要这个网站允许才能够接入，如果简单比喻的话：可以理解成是登陆网站的用户名。
App Secret简称API接口密钥，是跟App Key配套使用的，可以简单理解成是密码。
App Key 和 App Secret 配合在一起，通过其他网站的协议要求，就可以接入API接口调用或使用API提供的各种功能和数据。
比如淘宝联盟的API接口，就是淘宝客网站开发的必要接入，淘客程序通过API接口直接对淘宝联盟的数据库调用近亿商品实时数据。做到了轻松维护，自动更新。
2.1 UUID
UUID是指在一台机器在同一时间中生成的数字在所有机器中都是唯一的。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字 UUID由以下几部分的组合：
- 1、当前日期和时间。
- 2、时钟序列。
- 3、全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，以连字号分为五段形式的36个字符，示例：550e8400-e29b-41d4-a716-446655440000
Java标准类库中已经提供了UUID的API。
UUID.randomUUID()2.2 代码实现
- AppSecret 使用SHA-1生成20位byte数组，基本很难重复，再转化为40位16进制数字字符串。
- AppSecret使用sha-256生成32位byte数组，基本很难重复，再转化为64位16进制数字字符串。
三、API 接口开发安全性
接口的安全性主要围绕token、timestamp和sign三个机制展开设计，保证接口的数据不会被篡改和重复调用。
在代码层面，对接口进行安全设计
- 1、使用token进行用户身份认证
- 2、使用sign防止传入参数被篡改
- 3、使用timestamp时间戳防止暴力请求
3.1 使用token进行用户身份认证授权
具体说明如下：
- 1、 用户登录时，客户端请求接口，传入用户名和密文的密码
- 2、 后台服务对用户身份进行验证。若验证失败，则返回错误结果；若验证通过，则生成一个随机不重复的token(可以是UUID)，并将其存储在redis中，设置一个过期时间。
- 其中，redis的key为token，value为验证通过后获得的用户信息
- 3、 用户身份校验通过后，后台服务将生成的token返回客户端。
- 客户端请求后续其他接口时，需要带上这个token。后台服务会统一拦截接口请求，进行token有效性校验，并从中获取用户信息，供后续业务逻辑使用，Token是客户端访问服务端的凭证。
3.2 使用sign防止传入参数被篡改
为了防止中间人攻击（客户端发来的请求被第三方拦截篡改），引入参数的签名机制。
- 1、客户端和服务端约定一个加密算法（MD5或SHA-1算法(可根据情况加点盐)）， 客户端发起请求时，将所有的非空参数按升序拼在一起，通过加密算法形成一个sign，将其放在请求头中传递给后端服务。
- 2、后端服务统一拦截接口请求，用接收到的非可空参数根据约定好的规则进行加密，和传入的sign值进行比较。若一致则予以放行，不一致则拒绝请求。
由于中间人不知道加密方法，也就不能伪造一个有效的sign。从而防止了中间人对请求参数的篡改。
3.3 用时间戳防止暴力请求
时间戳超时机制 用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如5分钟），则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。
sign机制可以防止参数被篡改，但无法防dos攻击（第三方使用正确的参数，不停请求服务器，使之无法正常提供服务）。因此，还需要引入时间戳机制。
具体的操作为：
-
客户端在形成sign值时，除了使用所有参数和token外，再加一个发起请求时的时间戳。即 sign值来源 = 所有非空参数升序排序+token+timestamp
-
而服务端则需要根据当前时间和sign值的时间戳进行比较，差值超过一段时间则不予放行。
-
若要求不高，则客户端和服务端可以仅仅使用精确到秒或分钟的时间戳，据此形成sign值来校验有效性。这样可以使一秒或一分钟内的请求是有效的。
-
若要求较高，则还需要约定一个解密算法，使后端服务可以从sign值中解析出发起请求的时间戳。
总结后的流程图如下：
3.4 拒绝重复调用（非必须）
客户端第一次访问时，将签名sign存放到缓存服务器中，超时时间设定为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次。如果有人使用同一个URL再次访问，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的签名失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截。这就是为什么要求时间戳的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用（如抓取数据）。
在以上三种机制的保护下，如果有人劫持了请求，并对请求中的参数进行了修改，签名就无法通过；
如果有人使用已经劫持的URL进行DOS攻击，服务器则会因为缓存服务器中已经存在签名或时间戳超时而拒绝服务，所以DOS攻击也是不可能的；
所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出裁剪，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用Token机制就可以了。如何裁剪，全看项目实际情况和对接口安全性的要求。
四、基于AccessToken方式实现API设计
需求：
- A、B机构需要调用X服务器的接口，那么X服务器就需要提供开放的外网访问接口。
分析：
- 1、开放平台提供者X，为每一个合作机构提供对应的appid、app_secret。
- 2、appid是唯一的（不能改变），表示对应的第三方合作机构，用来区分不同机构的。
- 3、app_secret在传输中实现加密功能（秘钥），该秘钥可以发生改变的。
- 4、为什么app_secret是可以改变的？调用接口需要appid+app_secret生成对应的access_token（临时性），如果appid和app_secret被泄密，产生安全性问题，如果一但发现被泄密，可以重新生成一个app_secret。
原理：为每个合作机构创建对应的appid、app_secret，生成对应的access_token（有效期2小时），在调用外网开放接口的时候，必须传递有效的access_token。
4.1 开发步骤
4.1.1、使用appid+app_secret生成对应的access_token
- 1、获取生成的AppId和appSecret，并验证是否可用
- 2、删除之前的accessToken
- 3、AppId和appSecret保证生成对应唯一的accessToken
- 注意：以上第二步必须保证在同一事务中
- 4、返回最新的accessToken
4.1.2、使用accessToken调用第三方接口
- 1、获取对应的accessToken
- 2、使用AccessToken查询redis对应的value(appId)
- 3、如果没有获取到对应的appid，直接返回错误提示
- 4、如果能获取到对应的appid，使用appid查询对应的APP信息
- 5、使用appId查询数据库app信息，获取is_flag状态，如果为1，则不能调用接口，否则正常执行
- 6、直接调用接口业务
五、常见问题总结
做API接口，为什么access_token要放在Header头里传递？ 如果是OAuth2, 使用 Header传递token是属于规范的一种，Header中有一个Authorization头专门用于存放认证信息每一次登录，会生成一个新的Token, 此时旧的token并不会立即失效（取决于该token生成时，设置的失效时间）
六、代码实现
服务提供方
- 处理无法重复读取stream流,使之可以在一个stream流中多次读取同一个request值
www.cnblogs.com/owenma/p/11419341.html
www.cnblogs.com/yaoyu1983/p/12267809.html
blog.csdn.net/wjg8209/article/details/118806853
www.cnblogs.com/kevin-ying/p/10800934.html
www.jb51.net/article/239665.htm
www.jb51.net/article/239939.htm
blog.csdn.net/yaomingyang/article/details/108246334
本文共计4089个文字，预计阅读时间需要17分钟。
1. 什么是appid、appkey、appsecret？ - AppID：应用的唯一标识符。 - AppKey：官方（相对账户）。 - AppSecret：私钥（相对密码）。
2. token（过期失效）： - 令牌，用于身份验证，有效期内有效。
3. app_id： - 用于标记你的开发者账号。
一、什么是appid、appkey、appsecret
AppID：应用的唯一标识。 AppKey：公匙（相当于账号）。 AppSecret：私匙（相当于密码）
token：令牌（过期失效）
-
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 就可以验证权限了。
简化的场景
- 1、省去 app_id，他默认每一个用户有且仅有一套权限配置，所以直接将 app_id = app_key，然后外加一个app_secret就够了。
- 2、省去app_id 和 app_key，相当于 app_id = app_key = app_secret，通常用于开放性接口的地方，特别是很多地图类api 都采用这种模式，这种模式下，带上app_id 的目的仅仅是统计 某一个用户调用接口的次数而已了。
使用方法
- 1、向第三方服务器请求授权时，带上AppKey和AppSecret（需存在服务器端）
- 2、第三方服务器验证AppKey和AppSecret在DB中有无记录
- 3、如果有，生成一串唯一的字符串（token令牌），返回给服务器，服务器再返回给客户端
- 4、客户端下次请求敏感数据时带上令牌
二、云服务AppId或AppKey和AppSecret生成策略
App key简称API接口验证序号，是用于验证API接入合法性的。接入哪个网站的API接口，就需要这个网站允许才能够接入，如果简单比喻的话：可以理解成是登陆网站的用户名。
App Secret简称API接口密钥，是跟App Key配套使用的，可以简单理解成是密码。
App Key 和 App Secret 配合在一起，通过其他网站的协议要求，就可以接入API接口调用或使用API提供的各种功能和数据。
比如淘宝联盟的API接口，就是淘宝客网站开发的必要接入，淘客程序通过API接口直接对淘宝联盟的数据库调用近亿商品实时数据。做到了轻松维护，自动更新。
2.1 UUID
UUID是指在一台机器在同一时间中生成的数字在所有机器中都是唯一的。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字 UUID由以下几部分的组合：
- 1、当前日期和时间。
- 2、时钟序列。
- 3、全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，以连字号分为五段形式的36个字符，示例：550e8400-e29b-41d4-a716-446655440000
Java标准类库中已经提供了UUID的API。
UUID.randomUUID()2.2 代码实现
- AppSecret 使用SHA-1生成20位byte数组，基本很难重复，再转化为40位16进制数字字符串。
- AppSecret使用sha-256生成32位byte数组，基本很难重复，再转化为64位16进制数字字符串。
三、API 接口开发安全性
接口的安全性主要围绕token、timestamp和sign三个机制展开设计，保证接口的数据不会被篡改和重复调用。
在代码层面，对接口进行安全设计
- 1、使用token进行用户身份认证
- 2、使用sign防止传入参数被篡改
- 3、使用timestamp时间戳防止暴力请求
3.1 使用token进行用户身份认证授权
具体说明如下：
- 1、 用户登录时，客户端请求接口，传入用户名和密文的密码
- 2、 后台服务对用户身份进行验证。若验证失败，则返回错误结果；若验证通过，则生成一个随机不重复的token(可以是UUID)，并将其存储在redis中，设置一个过期时间。
- 其中，redis的key为token，value为验证通过后获得的用户信息
- 3、 用户身份校验通过后，后台服务将生成的token返回客户端。
- 客户端请求后续其他接口时，需要带上这个token。后台服务会统一拦截接口请求，进行token有效性校验，并从中获取用户信息，供后续业务逻辑使用，Token是客户端访问服务端的凭证。
3.2 使用sign防止传入参数被篡改
为了防止中间人攻击（客户端发来的请求被第三方拦截篡改），引入参数的签名机制。
- 1、客户端和服务端约定一个加密算法（MD5或SHA-1算法(可根据情况加点盐)）， 客户端发起请求时，将所有的非空参数按升序拼在一起，通过加密算法形成一个sign，将其放在请求头中传递给后端服务。
- 2、后端服务统一拦截接口请求，用接收到的非可空参数根据约定好的规则进行加密，和传入的sign值进行比较。若一致则予以放行，不一致则拒绝请求。
由于中间人不知道加密方法，也就不能伪造一个有效的sign。从而防止了中间人对请求参数的篡改。
3.3 用时间戳防止暴力请求
时间戳超时机制 用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如5分钟），则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。
sign机制可以防止参数被篡改，但无法防dos攻击（第三方使用正确的参数，不停请求服务器，使之无法正常提供服务）。因此，还需要引入时间戳机制。
具体的操作为：
-
客户端在形成sign值时，除了使用所有参数和token外，再加一个发起请求时的时间戳。即 sign值来源 = 所有非空参数升序排序+token+timestamp
-
而服务端则需要根据当前时间和sign值的时间戳进行比较，差值超过一段时间则不予放行。
-
若要求不高，则客户端和服务端可以仅仅使用精确到秒或分钟的时间戳，据此形成sign值来校验有效性。这样可以使一秒或一分钟内的请求是有效的。
-
若要求较高，则还需要约定一个解密算法，使后端服务可以从sign值中解析出发起请求的时间戳。
总结后的流程图如下：
3.4 拒绝重复调用（非必须）
客户端第一次访问时，将签名sign存放到缓存服务器中，超时时间设定为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次。如果有人使用同一个URL再次访问，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的签名失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截。这就是为什么要求时间戳的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用（如抓取数据）。
在以上三种机制的保护下，如果有人劫持了请求，并对请求中的参数进行了修改，签名就无法通过；
如果有人使用已经劫持的URL进行DOS攻击，服务器则会因为缓存服务器中已经存在签名或时间戳超时而拒绝服务，所以DOS攻击也是不可能的；
所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出裁剪，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用Token机制就可以了。如何裁剪，全看项目实际情况和对接口安全性的要求。
四、基于AccessToken方式实现API设计
需求：
- A、B机构需要调用X服务器的接口，那么X服务器就需要提供开放的外网访问接口。
分析：
- 1、开放平台提供者X，为每一个合作机构提供对应的appid、app_secret。
- 2、appid是唯一的（不能改变），表示对应的第三方合作机构，用来区分不同机构的。
- 3、app_secret在传输中实现加密功能（秘钥），该秘钥可以发生改变的。
- 4、为什么app_secret是可以改变的？调用接口需要appid+app_secret生成对应的access_token（临时性），如果appid和app_secret被泄密，产生安全性问题，如果一但发现被泄密，可以重新生成一个app_secret。
原理：为每个合作机构创建对应的appid、app_secret，生成对应的access_token（有效期2小时），在调用外网开放接口的时候，必须传递有效的access_token。
4.1 开发步骤
4.1.1、使用appid+app_secret生成对应的access_token
- 1、获取生成的AppId和appSecret，并验证是否可用
- 2、删除之前的accessToken
- 3、AppId和appSecret保证生成对应唯一的accessToken
- 注意：以上第二步必须保证在同一事务中
- 4、返回最新的accessToken
4.1.2、使用accessToken调用第三方接口
- 1、获取对应的accessToken
- 2、使用AccessToken查询redis对应的value(appId)
- 3、如果没有获取到对应的appid，直接返回错误提示
- 4、如果能获取到对应的appid，使用appid查询对应的APP信息
- 5、使用appId查询数据库app信息，获取is_flag状态，如果为1，则不能调用接口，否则正常执行
- 6、直接调用接口业务
五、常见问题总结
做API接口，为什么access_token要放在Header头里传递？ 如果是OAuth2, 使用 Header传递token是属于规范的一种，Header中有一个Authorization头专门用于存放认证信息每一次登录，会生成一个新的Token, 此时旧的token并不会立即失效（取决于该token生成时，设置的失效时间）
六、代码实现
服务提供方
- 处理无法重复读取stream流,使之可以在一个stream流中多次读取同一个request值
www.cnblogs.com/owenma/p/11419341.html
www.cnblogs.com/yaoyu1983/p/12267809.html
blog.csdn.net/wjg8209/article/details/118806853
www.cnblogs.com/kevin-ying/p/10800934.html
www.jb51.net/article/239665.htm
www.jb51.net/article/239939.htm
blog.csdn.net/yaomingyang/article/details/108246334