您需要以高精度定义您到底想要什么。

在这里，您希望允许您亲自访问。具有密钥的业务意味着将授予知道密钥的任何人/任何人的访问权限。在应用程序中嵌入密钥意味着应用程序知道密钥，而不是您；而且，正如您所注意到的，嵌入在广泛发布的应用程序中的秘密并不是真正的秘密。

所以，你必须清楚自己。首先，定义谁应该被授予访问权限，“谁”是指“人类”。该集合中的每个人都应该“知道”一个秘密值，服务器使用该秘密值来验证所述人的身份。如果几个人使用相同的秘密值，那么这个秘密的管理就会变得复杂，因为你不能强制遗忘：你不能把一个用户从“知道秘密”的人的集合中驱逐出去，因为他仍然会记住它。

因此，您应该拥有特定于用户的机密。每个人都应该有自己的秘密值，并将其发送到服务器以获得访问权限（因为我们正在讨论通过网络发送秘密，我假设所有这些都发生在 SSL 的保护下）。然后是用户如何在技术上存储他的秘密值的问题。如果他将它存储在他的脑海中，并在需要时通过键入它使其可供他使用的应用程序使用，那么这个秘密就是一个密码。但其他模型也是可能的，例如，秘密可能是一组随机生成的字节，用户将其存储在他的应用程序中的文件中。

您不能阻止有权访问您服务器的用户与其他任何人“共享”该访问权限；但是使用特定于用户的秘密，您至少可以：

1. 在服务器上知道谁（据称）正在连接，从而调整服务器将允许或禁止的操作集；
2. 通过删除秘密服务器端驱逐特定用户，而不影响其他用户。

你不能做的是拥有一个世界上每个人都可以下载、安装和使用来访问你的服务器的应用程序，同时可靠地防止任何不使用你发布的确切应用程序的访问。这将是防止盗版的圣杯，它被证明与它的神学对应物一样难以捉摸。

重申你的问题。

您在不受信任的客户手机上安装了移动应用程序。

移动应用程序必须获取/发送数据到您的网络服务；但是，您希望将访问您的网络服务仅限于移动应用程序，而不是任何随机用户（可能正在使用桌面设备，将其发布到网络上）。

您当前的解决方案是在应用程序中编码一个密钥，该密钥与每个请求一起传递给 Web 服务——只有具有正确密钥的请求才会得到处理。

完美的解决方案是不可行的

首先，您的目标对于老练的攻击者是不可行的。他们将能够反编译您的 android 应用程序的字节码，查看您的应用程序正在做什么，然后执行您的应用程序离线执行的任何操作。

但是，您可能能够使用android 应用程序许可功能来做大部分您想做的事情。

基本上，您可以在首次安装应用程序时为其生成一个唯一 ID。然后，您的应用程序向 google play 的“市场许可证服务器”发送查询，检查用户是否购买了此设备的应用程序，并发回许可证状态（使用 google 证书加密签名）。您的应用程序将此已签名的许可证状态传回您的服务器，服务器对其进行验证，并为该设备生成一个密钥（与唯一 ID 相关联）。

现在，如果某些应用程序过于频繁地使用您的 Web 服务（例如，您认为它离线），您可以禁止它的唯一密钥。

用户是否必须登录到应用程序？如果是这样，您可以使用凭据来验证请求。如果没有，那么在应用程序和 Web 服务之间拥有某种共享机密几乎是您能做的最好的事情。