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