仅向移动应用开放REST API的方案求教：可变应用密钥法

普遍观点都认为，要把公共REST API只限制给自家移动应用调用确实是个棘手的问题——毕竟移动应用的客户端代码很容易被逆向，固定的密钥、签名逻辑很容易被破解。不过我最近琢磨出一个「可变应用密钥法」，想听听各位同行的看法：

方案核心流程 #

• 移动应用端：获取当前设备的网络连接IP地址，通过我们预先约定的保密哈希算法（比如加盐的SHA-256）生成哈希后的AppKey，并在每个API请求的请求头或参数里带上这个AppKey
• 服务端：收到请求后，先获取该请求的源IP地址，用完全相同的保密算法+加盐规则生成AuthKey，然后对比AppKey和AuthKey是否匹配
• 校验逻辑：如果两者完全一致，就认为请求来自自家合法应用，允许继续处理；如果不匹配，则直接拒绝请求

我初步考虑到的优势 #

• 规避固定密钥泄露风险：每次请求的AppKey都是基于实时IP生成的，就算有人抓包拿到某次的AppKey，换个IP或者下次请求就直接失效了
• 实现成本较低：不管是客户端获取IP还是服务端校验IP，都是比较常规的操作，哈希算法也有成熟的现成实现

目前存疑的待探讨点 #

• 代理/网关场景：如果用户用了代理、VPN或者运营商共享IP，会不会出现客户端获取的IP和服务端拿到的源IP不一致的情况？这时候校验就会失败，影响合法用户的正常使用
• 逆向破解风险：如果有人逆向出了客户端的哈希算法和加盐规则，是不是可以模拟IP生成合法的AppKey？虽然比破解固定密钥难度高，但还是存在被突破的可能
• 多网络连接场景：有些设备可能同时有多个网络连接（比如Wi-Fi+蜂窝数据），客户端获取的IP会不会和实际请求的出口IP不一致？

想听听大家对这个方案的看法，有没有什么我没考虑到的漏洞，或者可以优化的地方？

内容的提问来源于stack exchange，提问作者DeepBlue