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