这样的明文接口设计是否已经满足了大多数场景下的 openapi 的安全要求

前提说明：面向应用的 openapi 调用(不使用 ouath 验证)

首先分配给调用方 appKey(用于身份校验)和 appSecret(用于签名)

接口基本构成 appKey,reqId,timstamp,业务参数，sign

最后的参数 sign = md5(appSecret+appKey=xxx+reqId=xxx+timestamp=xxx+username=xx+vip=xxx+appSecret) 参数是以 key 增序排列的 增加了 reqId (使用 UUID)用来防范重放攻击

说明： 我们假定 timestamp 的有效时间是 1 小时，即 now-1 <timestmap< now+1 都是有效的 这时 reqId(存储在 redis 中)我们设置有效时间是 1 小时 校验逻辑是先验证签名，再验证 timstamp 有效性，再验证 reqId 有效性。 sign 保证了传输过程中没有被篡改，timestamp+reqId 保证没有重放攻击（因为在接下来的一个小时内，重放攻击发生时，因为 reqId 已经使用过，服务会被拒绝。过了这个小时，重放攻击会因为 timstamp 失效而被拒绝服务）

后端:reqId 存放在 redis，appSecret 也存放在 redis 用来提高访问性能

后续：启用 https 可以防止明文传输被人解读