听起来您想向用户验证 Cordova 应用程序二进制文件添加,以确保向 PHP 服务器发出的 REST API 请求来自合法来源,而不是流氓应用程序或最终可以通过反向工程 API 抓取后端数据的脚本。
OAuth/OpenID 流程通常用于对用户进行身份验证,而不是移动应用等软件,重要的是要记住,真正经过身份验证的用户仍然可以利用假软件利用 REST API。
你有两个选择:
- 自己动手
- 购买现成的解决方案
使用 HMAC 对来自移动应用程序的 API 请求进行签名当然是个好主意,但回想一下,HMAC 函数将密钥和消息作为参数,并且密钥最终必须在内存中以单一形式存在(即使最初被混淆)如果使用无法混淆的内置系统版本的 HMAC,则可以从移动应用程序中提取。
我强烈建议不要在移动应用程序中嵌入秘密 - 一旦应用程序在各种商店上公开可用,移动应用程序使用的秘密和 API 就可以通过逆向工程过程获得。
如果您决定在您的应用中使用 HMAC 请求签名方法,那么您绝对应该实施:
- 调试检测
- root/越狱检测
- 仪器框架检测(如Frida),以及
- 中间人网络代理检测
同时,在消息中进行编码,以便通知 REST API,以便它可以做出保护自己的决定。此外,在本机代码中执行任何这些操作 - 而不是在 Cordova Javascript 代码中,因为该层和 JS/本机桥接层在移动应用程序中引入了一个弱点。
您提到了“公钥”,但在非对称加密(例如 RSA)中,该密钥通常用于加密和验证操作。私钥用于解密和签名操作,因此它是您在应用程序中需要的 private 密钥。我永远不会提前嵌入这个。
您还可以在 HMAC 消息中包含应用的开发者签名权限,这有助于防止重新打包的版本被其他人签名。
带内 HMAC API 请求签名的另一种方法是使用带外标记化方法,该方法使用 JWTs 来表示移动应用程序的有效性。您可以在远程软件身份验证服务器上定期执行移动应用程序有效性测试,为移动应用程序提供 JWT,该 JWT 可以包含在每个 REST API 请求中。例如,Approov 就是这样做的。
不要将应用程序强化(混淆、字符串加密等)与 REST API 保护混淆,这一点也非常重要:在前一种情况下,您会在移动应用;在后一种情况下,您会在 REST API 后面的 data 中看到值。
除非您有足够的资源,否则这是一个很难有效解决的问题,因此我建议您使用其他人已经解决了这些问题的解决方案,这样您就可以将精力集中在应用功能、用户体验和上市时间上。
无论您做出什么决定,+1 表示积极关注安全,我希望这对您有所帮助,并祝您项目顺利!