需求
业务表示要把各种垂直领域第三方对接进来。好啊这个以前没有搞过，又可以折腾了。
先从技术和风险角度分析一下需求，不能来一家做一下后台对接开发，那不累死了。涉及到钱，一般风险都有被冒名顶替骗了、对面不认账等。稍微整理一下，得到以下需求。
- 要确定是对接的第三方之一发送的，不能随便哪个阿猫阿狗都能发请求，第三方需要证明“ta”是“ta”。
- 防止第三方抵赖不认账，不然做了个几百万，抵赖不认，作为无证程序员被开，亏大了。
- 防止中间被劫持，请求被篡改或者重放。
设计
“所有客户端都是不可信的。”——至理名言，所以采用后台（ web api ）对接。
证明 ta 是 ta
首先，第三方你要跟我对接，好，我先发个“狗牌”给你—— App ID 。你每次请求，都把 App ID 带上，我就知道是你了。
但是，其他人知道了，拿这个 App ID 发请求怎么办？
简单，我再发给你一个 App Secret ，每次发送请求你拿着 App Secret 签个名（ sign ），只要你不把 App Secret 泄露，我拿着你的签名比对一下，我就知道是你了。你说什么？我也不会去泄露你的 App Secret 的。
举个栗子。
// 第三方发送的原始请求
/uri?a=1
// 添加签名
/uri?a=1&appid=[the app id]&sign=[signed app id value]
注：这里是个厂里的风险点，参考最近某厂用户数据泄露。所以这里考虑，比如将 App ID 和 App Secret 的生成分为 AB 角，记录操作等。
再注：签名一般用一个哈希（或者说散列）算法。常用的有 MD5 、 SHA-1 、SHA-256 等等。最近大佬们说 MD5 和 SHA-1 已经被玩坏了不安全了，而且各种用 SHA-1 签名的支持 HTTPS 的网站都会被 Chrome 、 Firefox 等警告网站不安全，所以签名还是用 SHA-256 吧。
防止抵赖
考虑一下，我收到一个请求。
// 第三方下了个单，ta 高速我标识是 1 ，金额 1000 元。
/uri?orderno=1&amount=1000&appid=[the app id]&sign=[signed app id value]
之后就不认账。“我没发过啊”或者“我发的单明明是 1 块钱”。这可如何是好。干脆把请求参数一起签名吧。
具体实施起来，大致和各种大厂第三方对接一致，参考微信支付签名算法。
- 参数名ASCII码从小到大排序（字典序）。
- 如果参数的值为空不参与签名。
- 参数名区分大小写。
- 验证调用返回或微信主动通知签名时，传送的sign参数不参与签名，将生成的签名与该sign值作校验。
- 接口可能增加字段，验证签名时必须支持增加的扩展字段。
这个方法，同时能防止第三条，请求被劫持时被篡改。
防止劫持
这个其实没有特别好的办法咯，基本就是：
- 使用 HTTPS 。
- 限制请求来源 IP 地址。
防止重放
简单的办法就是加一个时间戳。
总结
关键技术点就这么多了，剩下的就是前置的申请对接流程和后续的一些如申请 App ID 和 App Secret 更新等流程。
正所谓太阳底下没有新鲜事，要搞什么事情，参考参考其他厂的开放文档，基本就能理清应该怎么做了。
