我知道这个问题以前已经以各种形式被问过。但是，我并不是在寻找“使用 https”答案。我已经在使用 HTTPS，并且不担心来回传输的有效负载的敏感性。
但是，我正在开发的 iPhone 应用程序正在与我构建的 REST API 进行通信(我可以控制应用程序和服务器 - 因此欢迎提出任何建议)。
我使用 OAuth2 协议(protocol)进行身份验证，这意味着我的“API key ”是客户端 ID 和客户端 key 的组合，仅需要传输它们来获取 access_token。之后，所有请求都使用 access_token 和包含请求正文 HMAC 的 header (使用客户端 key 作为 key )发送到服务器。添加此内容的唯一原因是其他人无法仅使用 access_token 发出 API 请求。
当我发布应用程序时，我正在谈论的 API 将被公开。所以我不一定担心其他人能够对其进行 API 调用。
我关心的是:
- 人们能够使用我的应用程序的客户端凭据进行 API 调用(这意味着我无法在服务器端检测到它不是来 self 的应用程序)
- 人们能够滥用我的客户端 ID 允许他们拥有的额外范围，而传统 API 用户不会拥有
我的猜测是，这个问题并没有真正的解决方案(除了使用 UIWebView 并制作一个美化的 web 应用程序)，但我想我还是会在这里问一下。
如果应用需要使用客户端 ID/客户端 key ，你们能想出一种方法来保护它吗？
最佳答案
我知道这不是您所希望的答案，但不幸的是，我认为您无法绝对保证实现您的目标。归根结底，您不能信任您无法控制的客户，而且一旦它离开您的手，您就无法控制它。
为了实现您的两个目标，您需要验证访问 API 的客户端是否是您编写的。做到这一点的方法是使用公钥/私钥对。您需要将私钥嵌入到客户端中，以便客户端可以用来签署某些内容。这样服务器就知道请求来自您的客户端而不是其他人的。这还允许您将某些调用限制为仅限您的客户端。
但是，这并不是万无一失的，因为精明的用户可以进行逆向工程并从您的应用程序中提取私钥并使用它来欺骗源。虽然不是防弹的，但它是防弹的，因为这样做需要大量的工作并且技术含量很高，特别是如果您使用反 RE 技术，如缓冲区涂抹、大量转移注意力等。
如果我是你，我会问自己，如果有人肯定入侵了它，会造成什么类型的损害。如果你是 Facebook，那将是灾难性的。如果您为内部组织服务，这可能根本不是什么大问题。如果你无法承受一次滥用，那么你需要重新考虑你的设计，因为这个是行不通的。您根本无法信任您无法控制的代码，并且一旦客户端位于其他人的设备上，您就无法再控制客户端。
关于iphone - 在 iPhone 应用程序中使用 REST API 时的安全性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15273705/