当前，我在登录并使用它进行http请求后，将从服务器获得一个API密钥。我目前将API密钥存储在iPhone应用程序的数据库中。但是，我听说我应该从同事那里把它存储在keychain中。所以，我在Stackoverflow上搜索了一下，发现了有关这方面的问题。这似乎根本不是一种存储API密钥的安全方式。
iOS应用程序场景中的安全密钥，安全吗？
在iOS中，我如何存储一个秘密"键"；这将允许我与服务器通信？
我不知道如何阻止黑客通过逆向工程从iOS应用程序中获取API密钥。StackOverflow上的一位用户基本上说，它只会使事情过于复杂，几乎没有好处。
我需要找到这篇文章，但有人建议你只需确保你提出了一个安全的API请求(SSL证书)，并且如果有人被黑客入侵，你有办法删除API密钥。
@jake已经指出，您应该使用仅与用户绑定的令牌，而不是所有用户的Api-Key，但在执行http请求时，还可以进行其他增强，以进一步保护您的应用程序。
用户令牌可以是签名的JWT令牌，然后您可以通过证书钉扎来增强服务器与应用程序之间通信的安全性，以防止中间人攻击。
其他技术，如使用OAUTH2和隐藏机密，可以用来增强应用程序的安全性，您可以在此处阅读更多信息。
请记住，证书钉扎可以通过挂钩Xposed等框架来绕过，这些框架包含特定于绕过钉扎的模块，但一旦它增加了在设备上破解应用程序所需的工作量，并将保护您的应用程序免受中间人攻击，您就不应放弃另一层安全。
为了确保应用程序和后端之间的最终安全，您应该使用应用程序完整性证明服务，该服务将通过使用集成在应用程序中的SDK和在云中运行的服务，在运行时保证您的应用程序未被篡改或未在根设备中运行。
在成功证明应用程序完整性时，将使用只有您的应用程序后端和云中的证明服务知道的秘密颁发和签署JWT令牌，而在失败时，将用应用程序后端不知道的假秘密签署JWT，允许应用程序后端仅在可以验证JWT令牌中的签名时提供请求，并在验证失败时拒绝请求。
一旦应用程序不知道云证明服务使用的秘密，即使应用程序被篡改、在根设备中运行或通过作为中间人攻击目标的连接进行通信，也不可能在运行时对其进行逆向工程。
你可以在Approv中找到这样一个服务，它有几个平台的SDK，包括IOS。集成还需要在应用程序后端代码中进行少量检查，以验证JWT令牌，以便后端能够保护自己免受欺诈使用。
JWT代币
基于令牌的身份验证
JSON Web令牌是一种开放的、行业标准的RFC 7519方法，用于在双方之间安全地表示声明。
证书锁定
Pinning是将主机与其期望的X509证书或公钥相关联的过程。一旦知道或看到主机的证书或公钥，就会将证书或公钥关联或"固定"到主机。如果可以接受多个证书或公钥，则该程序将保存一个pinset(取自Jon Larimer和Kenny Root的Google I/O对话)。在这种情况下，播发的标识必须与针集中的某个元素匹配。
OAUTH2
OAuth 2.0授权框架支持第三方应用程序以获得对HTTP服务的有限访问权限，在通过协调审批交互来代表资源所有者在资源所有者和HTTP服务之间，或者通过允许第三方应用程序以自己的名义获得访问权限。这该规范取代并废弃了所描述的OAuth 1.0协议在RFC 5849中。
免责声明：我在Approvov工作。
更安全的机制是在登录时返回身份验证令牌。此身份验证令牌对用户来说应该是唯一的。如果你在后端有适当的授权和安全机制(以减轻DDOS攻击、注入攻击、用户访问其他用户的数据等)，那么谁在乎他们是从密钥链还是从存储密钥链的任何地方获得授权令牌呢？由于身份验证令牌与他们的帐户绑定，您可以使令牌无效，以便在用户恶意时停止工作。如果你在后端有合适的机制，你甚至可以完全禁用他们的帐户。
许多安全机制可以在后端实现自动化。像AWS这样的平台可以很容易地配置为自动禁用对后端进行某些恶意调用的帐户。