使用回调机制提高接口安全性

发表于 |

前言

  • 接口回调在平常的业务开发中并不罕见。做过渠道推广业务，对接过广告平台接口的同学应该比较熟悉。
  • 在业务的作用主要是两个
    1. 异步通知
    2. 业务查询

本文主要讲的第二种，并通过一个业务例子来展开描述

业务描述

有以下业务场景，用户通过充值加金币：

充值请求----------> 服务A（充值服务）
             [1.验证用户已经支付成功]
             [2.发起加金币请求]------------>服务B（金币服务）

  • 服务B如何验证加金币操作的请求是合法，从而保证资金安全呢？

    • 有一种方法是通过分配业务对应的秘钥和服务端签名对比，验证请求的合法性

  • 通过秘钥和验签的方式无法避免以下问题

    1. 其他业务方误用秘钥
    2. 因误操作而发加币请求
    3. 业务方有bug一次充值多次加币

解决方案

  • 其实以上描述的业务有一个特点：每一次操作都有对应的前置操作，比如
    1. 充值加金币的前置操作是：充值支付成功
    2. 活动类加金币的前置操作是：用户达到活动要求

那么作为底层的金币服务，可以使用定义一种同样的回查机制，由各业务方实现查询逻辑，金币服务通过回查来检验请求的合法性，从而提高安全性。

  • 基础服务（金币服务）接收回调链接地址有两种方式：
  1. 通过后台配置，每个业务配置对应回调链接和相应的参数 （相比可能比较安全可控，但不灵活）
  2. 通过参数获取，如callback参数（灵活，但是要设计完善的校验机制保证安全）
    • 可结合公司的基础服务实现，如可以通过服务发现获取服务对应的地址，只需传uri即可
充值请求----------> 服务A（充值服务）
             [1.验证用户已经支付成功]
             [2.发起加金币请求]------------>服务B（金币服务）
                                <----------[3.回调验证] [4.加金币] < pre>


    

  • 统一回调接口返回格式
    • 



回调接口返回格式
{
    "code": 0,
    "message": "success"
}
0 代表成功；其他：失败

回调用于查询业务订单是否存在，检验是否非法订单
一般实现逻辑建议业务方直接查主库




    

  • 回调无法绝对解决以上提出的问题，只能说一定程度上提升接口的安全性级别。
    • 



扩展
    

  • 使用非对称加密，是不是可以替换回调验证？（客户端使用公钥解密，服务端使用私钥加密，前提是私钥不泄漏）
    •