我知道以前曾以各种形式提出这个问题。但是，我不是在寻找“使用https”的答案。我已经在使用HTTPS了，我并不担心有效载荷来回传输的敏感性。
但是，我正在处理的iPhone应用程序正在与我构建的REST API进行通信（我可以控制应用程序和服务器 - 所以欢迎任何建议。）
我使用OAuth2协议进行身份验证，这意味着我的“API密钥”是客户端ID和客户端密钥的组合，仅需要传输以获取access_token 。之后，使用access_token和包含请求正文的HMAC的标头（使用客户端密钥作为密钥）将所有请求发送到服务器。这种添加的唯一原因是，有人无法使用access_token进行API请求。
我正在谈论的API将在我发布应用程序时公开。所以我不一定担心其他人能够对它进行API调用。
我关心的是：
我的猜测是，这个问题并没有真正的解决方案（除了使用UIWebView并制作一个美化的webapp），但我想我还是会在这里问一下。
如果应用程序需要使用客户端ID /客户端密码，您是否都能想到保护客户端ID /客户端密钥的方法？
答案 0 :(得分：7)
我知道这不是你所希望的答案，但不幸的是我不认为你可以绝对保证完成你的目标。在一天结束时，您无法信任您无法控制的客户，并且一旦您离开您的手，您就无法控制它。
为了实现您的两个目标，您需要验证访问API的客户端是否由您编写。这样做的方法是使用公钥/私钥对。您需要将一个私钥嵌入客户端，它可以用来签名。这样，服务器就知道请求来自您的客户而不是其他人。这也允许您将某些呼叫限制为仅限您的客户。
但是，这不是防弹，因为精明的用户可以从您的应用程序进行逆向工程和提取私钥，并使用它来欺骗源。虽然不是防弹，但它是防弹的，因为这样做需要大量的工作并且技术性很强，特别是如果你使用反RE技术，如缓冲涂抹，质量红鲱鱼等。
如果我是你，我会问自己如果有人肯定会攻击它会造成什么类型的伤害。如果你是Facebook，那就是灾难性的。如果您在内部组织服务，那可能不是什么大问题。如果您无法承受单一的滥用行为，那么您需要重新考虑您的设计，因为这个设计无法运作。您根本无法信任您无法控制的代码，而且一旦客户端设备无法控制客户端，您就无法控制客户端。