我的服务允许使用POST请求将任何HTML文档转换为PDF。 它主要用于我的客户端服务器的后端，因此，用于通信的API密钥保持私有状态。
现在，我正在考虑一种方法，使客户的访问者能够代表我的客户端API密钥调用我的服务，而无需暴露此安全的API密钥。
我这里的主要问题是安全性。如果我的客户添加了包含API密钥的XHR POST请求，则有人可以获取该API密钥并将其用于自己的目的并滥用我的客户帐户。
我可以按域进行过滤，但这很容易被欺骗，因此这是不可能的。
我想知道是否有一种方法可以从客户端（客户端）调用私有服务并在不冒其身份被盗的情况下被识别？
答案 0 :(得分：2)
如果您要为经过身份验证的用户提供此子租约，那么给他们提供唯一的密钥就很简单了（某些东西会针对API密钥和初始时间戳对用户ID或会话进行哈希处理，然后对其进行检查/记录/查找在访问API之前先进行暴力破解）。如果您是在开放的Web上进行操作，而没有任何类型的用户身份验证，那么速率限制的确非常棘手。通常，您需要结合使用会话哈希，IP地址，操作系统和浏览器数据来创建匿名配置文件，该配置文件在前端获得临时密钥。一种相当可靠的方法是在提供临时密钥之前强制用户通过CAPTCHA，该临时密钥允许他们有限次数地使用永久密钥。 ip /浏览器/会话与已知客户端密钥的现有属性匹配的任何用户都将被分流到该用户（并跳过了验证码）；任何与现有个人资料不匹配的人都将获得验证码。这使您成为欺骗的吸引力较小的目标。最重要的是，您应该始终根据您期望（或负担得起）的流量类型，在合理的每日点击次数内对整个事物进行速率限制，以免出现任何意外。如果您的客户每次使用他们的API密钥时都花钱，这就是您想要的最低安全性。它将需要一个简单的数据库来存储这些“配置文件”，跟踪使用情况，检查暴力并维护当前有效的客户端密钥。客户端密钥应始终定期过期-有时与创建密钥的时间有所不同，或者是定期的cron流程，或者最大使用次数等。
我经常做的另一件事是基于曲线的速率限制。例如，如果我认为每分钟5次使用是合理的，则在会话后一分钟内进行5次使用后，每次使用都会增加几分之一秒的延迟*数据之前最后一分钟的使用次数平方被送达。
最好的答案是将其全部放在登录系统后面并保护那个。
答案 1 :(得分：1)
没有很好的方法进行前端安全存储，但是我的建议是：
是一个使用HMAC签名请求与OAuth身份验证结合使用的API。 API密钥实际上是一个签名密钥。他们的密钥不会被转移。该API密钥仍然可以在前端找到，但是它变得无用，因为您仍然需要OAuth令牌来发送有效请求。
我知道用户将必须登录，但是您可以将其视为一种优势，因为至少可以通过从oauth获取信息来登录谁在使用该应用程序。
请考虑使用后端安全存储！
答案 2 :(得分：1)
假定您使用的是OAuth类型的系统，在这种情况下，请使用访问令牌机制，该机制可代表用户（客户端）提供对私有API /用户数据的访问，而无需暴露其凭据或API密钥（身份验证）键），访问令牌也可以根据时间/使用情况而过期。
示例：访问令牌是针对单个端点生成的，该端点可以是Html转换端点，并且在操作完成后将过期。
https://auth0.com/docs/tokens/access-token
以下博客文章将有助于构建您的身份验证系统 https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
答案 3 :(得分：1)
我认为您可以使用JWT令牌。根据用户名，密码或任何其他信息，您可以为不同用户生成唯一的jwt令牌。 任何人都可以解密这些jwt令牌，但不能解密唯一的安全令牌。
如果要为令牌添加更多安全性，请使用JWE（加密的Web令牌）。
有关这些方案的更多信息，请访问https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
答案 4 :(得分：0)
散列是一个不错的选择，无论如何都应该进行散列，但是对于不会增加太多复杂性的完全安全的方法，您可以通过构建自己的API与API的接口来简单地从授权/ API密钥中抽象出来。这样，您不仅可以限制使用API密钥可以完成的事情，还可以完全掩盖用户对API密钥的了解