仅将REST API限制为移动应用程序-建议的方法

我读了很多书，说你不能将你的公共REST API仅限于你的移动应用程序，但我有一个想法，我想听听你的意见：

可变应用程序密钥方法

移动应用程序

获取当前连接的IP地址

使用秘密算法从IP地址生成哈希AppKey

在每个API请求中发送AppKey

服务器端

检查传入请求的IP地址

使用相同的秘密算法从该IP地址生成AuthKey

比较AuthKey和AppKey，如果它们匹配，那么您就知道 应用程序正在与您交谈，因为只有应用程序知道 秘密算法

当IP地址更改时：

• 在移动应用程序上，使用新的IP地址重新生成AppKey
• 服务器端将始终生成相同的密钥，因为这取决于 关于请求的IP地址

这样做的主要优点是AppKey总是会更改，这比在代码中硬编码1个应用程序密钥要好，读取请求头很容易窃取应用程序密钥。即使您从用户那里偷了AppKey，您也必须使用生成该密钥的相同IP地址

有什么想法吗？

“秘密”算法必须在应用程序中。。。给每个人。这根本不是秘密。隐晦的安全性是不好的，无论如何，你不应该有所谓的秘密算法，因为保守秘密是没有希望的。在这种情况下，算法被琐碎地揭示出来

另请参考施奈尔定律。：）

编辑：

所以从理论上讲，这永远不可能是安全的，因为你放入应用程序的任何算法都需要在客户端上运行，因此可以进行分析和反编译。但有人可能会争辩说，它不需要在理论上是安全的，如果它“足够安全”，也就是说，风险足够低，因为例如，实现算法所需的努力太多了

但是考虑两种可能的选择：

• 这是一个非常酷的API，每个人都想为它构建一个客户端，或者至少有一个这样的团体。在这种情况下，不费吹灰之力，算法将被“破坏”，也就是说，它将被反编译并在不同的客户机中实现

• 人们并不太关心这个API，对于其他人来说，构建一个客户端并不重要。在这种情况下，他们可能无论如何都不会构建客户机，可以使用更简单的方法来防止其他客户机以合理的成功出现

---

但是很明显，这是你的选择，一种类似于你描述的方法确实提高了标准——只是不要期望它实际上是安全的，因为它不会。反编译代码有那么容易吗？在编译的C++代码中制作秘密算法，并将其与java应用程序集成在一起？这将很难实现decompile@DeepBlue我延长了我的回答。