一个完善的 API 流程标准(草图)

peixinchen

目的

  1. 保证 API 本身是安全的,不会受到以下(包括但不限于)手段的攻击:

    1. 重入攻击;

  2. 保证调用方是可以管理的,包括但不限于:

    1. 来源模块是可控的;

    2. 来源设备是可控的;

    3. 调用频率是可控的;

  3. 整个调用链条是可追踪的,即从接入层一直到数据层是相关的;

设计思路

概念

  1. APPID: 标明调用方的唯一标识;

  2. JWT: Json Web Token,一种标准化的对称加密机制;

  3. JWT-Signature: 使用 JWT 加密后的密文;

  4. LOGID: 由接入层生成的调用链条唯一标识;

思路说明

  1. 调用方在使用 API 时,需要先进行授权申请,获取唯一的 APPID 及 APPSECRET;

  2. 调用方需要报备调用设备的请求 ip;

  3. 调用方需要申请一定的请求频率(在使用默认值的情况下,这个步骤可以忽略);

  4. 调用方在请求 API 时,需要进行如下步骤:

    1. 将下游传给自己的 LOGID 作为调用链条的唯一标识,继续向上游进行传递,如果调用方是接入层,则按一定规则生成一个唯一串作为本次调用链条的唯一 LOGID(这个步骤是为了完成目的 3);

    2. 使用申请到的 APPSECRET 对包括当前请求时间 + 请求参数的组合的签名 进行 JWT 加密;

    3. 将 APPID 和 第 2) 步生成的签名一并传递给上游;

  5. 服务提供方在接到请求时,按以下步骤验证其合法性:

    1. APPID、JWT-Signature、LOGID 是否存在,否则不合法;

    2. APPID 是否被授权访问该 API,否则不合法;

    3. 实际请求 ip 是否和 APPID 报备的请求 ip 匹配,否则不合法;

    4. 根据 APPID 对应的 APPSECRET 解密 JWT-Signature 是否正确,否则不合法;

    5. 请求时间是否超时,否则不合法;

    6. 请求参数的组合的签名是否一致,否则不合法;

    7. 请求频率是否小于分配给该 APPID 的频率限制,否则不合法;

    8. 请求频率是否小于该 API 的全局频率限制,否则不合法;

  6. 在服务提供方记录日志及请求其上游时,将 LOGID 进行记录及传递;

阅读 3.1k

peixinchen
peixin.chen

peixinchen.me

347 声望
7 粉丝
0 条评论

peixinchen.me

347 声望
7 粉丝
文章目录
宣传栏