本文是小编为大家收集整理的关于REST网络服务和API密钥的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我有一个Web服务，我提供给用户挖掘我的应用程序数据库并获得一些信息.用户必须注册API键并在提出请求时提供.一切都适用，但如何检查为关键注册的用户实际上是提出要求，而不是他可能给予钥匙的其他人?
我一直在想过去两天来提出一个解决方案，但到目前为止没有任何东西.
推荐答案
您需要使用签名请求.基本上它是这样的:
- 您将您的用户提供API键和一个只有您和客户知道的"秘密"(一个随机字符串).
- 每当他们提出请求时，它们都会向其添加"签名"参数.此签名基本上是请求参数+ API键+其他参数的哈希(见下文)+秘密.
- 由于您也知道秘密，您可以验证签名是否正确.
这是或多或少如何在 oauth 中签名.在链接中查看他们的例子.
其他推荐答案
验证REST API调用有2个部分.当用户使用服务注册时，您通常将分配识别该用户的密钥.有时，这就足够了.但是这个关键可以分享或被盗.在这种情况下，您的服务仍将考虑有效的关键.现在，为了防止密钥劫持等.您还将分发一个秘密密钥.此密钥从未使用REST API请求运输.此键用于执行API请求的一种方式哈希，并创建签名(HMAC).
此签名，加上API请求(以URL形式的HTTP请求)发送到API服务器.服务器执行URL的一种方式散列，并使用本用户的私钥与签名进行比较.如果它们匹配，请求者可以访问私钥，因此请求有效.
为了避免重放攻击，除了随机(正如上一张海报的建议)，您还可以使用哈希链接.
问题描述
I have a web service I'm offering to users to tap into my applications database and get some info. Users have to register for an API key and provide that when making requests. Everything works fine but how do I check if the users who registered for a key is actually making the request and not somebody else who he might have given the key to?
I've been thinking for the last two days to come up with a solution but nothing so far.
推荐答案
You need to use signed requests. Basically it works like that:
- You give your user an API key and a "secret" (a random string) that only you and the client know.
- Whenever they make a request, they add a "signature" parameter to it. This signature is basically a hash of the request parameters + the API key + other parameters (see below) + the secret.
- Since you know the secret too, you can verify that the signature is correct.
To avoid replay attacks, you can also add nonces and timestamps into the mix. A nonce is simply a number that must be incremented by the client on each request. When you get the request, you check if you've already received this nonce/timestamp before. If you did, you reject the request (because it's most likely a replay attack). If not, you store the nonce/timestamp in your database so that you can look it up later on.
This is more or less how requests are signed in OAuth. Have a look at their example in the link.
其他推荐答案
There are 2 parts to authenticating REST API calls. When a user registers with your service, you will typically assign a KEY identifying that user. Sometimes, this is enough. But this KEY can be shared, or stolen. In which case, your service will still consider the KEY to be valid. Now, in order to prevent key hijacks etc. you will also distribute a secret key. This key is never transported with the REST API request. This key is used to perform a one way hash of the API request, and create a signature (HMAC).
This signature, plus the API request (HTTP request in the form of URL) is then sent on to the API Server. The server performs the one way hash of the URL and compares with the signature using the private key of this user. If they match, it is "assumed" that the requester has access to the private key, and therefore the request is valid.
In order to avoid replay attacks, in addition to nonce (as suggested by the previous poster), you can also use hash chaining.
更多相关问答
联系站长