想象以下场景：
我已经构建了一个 API 和一个 Web 应用程序。用户将通过 Web 应用程序注册，并收到唯一的 API 密钥。然后他们可以为他们的账户购买“信用”，这只是美元的 1:1 表示。
当用户执行 API 调用时，他们会传入他们的 API 密钥。此键用于识别客户，并根据需要减去信用。
这里有一个明显的问题。如果用户从他们自己的服务器执行这个调用，并且密钥是保密的，那么一切都很好。但是，我将如何处理没有自己服务器的客户？例如，假设一个用户在没有服务器的情况下向 Play 商店发布了一个简单的 Android 应用程序，并且想要集成我的产品。密钥必须保留在客户端。然后，恶意用户可以对应用程序进行反混淆，并可能执行未经授权的 API 调用，从而花费密钥所有者的信用。
如何解决这个问题？有没有办法处理这种情况？
该问题的一个明显解决方案（通常）是拥有一个管理 API 密钥的服务器（因此不允许直接移动应用程序 -> API 访问）。这样，中间服务器将管理 API 密钥，对于中间应用程序的所有调用者来说，该密钥可以相同也可以不同。此应用程序可以对其调用者进行身份验证，并可能根据登录用户决定使用哪个 API 密钥。这可能很容易出错，特别是从长远来看，如果有多个人或团队开发它。这也只是进一步推动问题。:)
但是假设您希望移动应用程序能够安全地与 API 对话。为什么必须在应用程序中对密钥进行硬编码？
对此的标准解决方案是，下载应用程序的用户在运行时从 API 获取自己设备上的 API 密钥。所以没有设置密钥，因为你在 API 端不知道你的用户是谁。一旦有用户（来自移动应用程序或其他任何东西），您创建一个 API 密钥，移动应用程序可以按照它想要的方式存储它（顺便说一句，这是一整罐蠕虫，长话短说，可能是内置的 -在移动平台的凭证存储中最好）。
您的困惑可能来自于没有确定 API 密钥的确切标识。如果是用户（最终用户有自己唯一的 API 密钥），那么就像上面描述的那样，他们应该单独获取他们的密钥。另一方面，如果 API 密钥识别您的客户端（移动应用程序制造商），那么他们需要有一个服务器，否则它将不安全。