Why use an API key and secret?

问题:

I came across many APIs that give the user both an API key and a secret. But my question is: what is the difference between both?

In my eyes, one key can be enough. Say I have a key and only I and the server know it. I create a HMAC hash with this key and do an API call. On the server, we create the HMAC hash again and compare it with the sent hash. If it's the same, the call is authenticated.

So why use two keys?

Edit: or is that API key used to lookup the API secret?

回答1:

Secret key cryptography relies on using the same key to encode and then later decode a message. Thus, only those who know the "secret" can read the message.

RSA security is based on 2 matching keys. There is a public key for each user, and everybody can (should) know it. There is also a private key that only the user should know. A message encrypted by the public key can only be decrypted by the private key, and visa versa.

Thus, if I want to send you a message that only you can read, I get (from the network) your public key, encrypt the message with that key and you are the only person who can decrypt it.

Or, if I want to prove to you that I sent a message, I can encrypt the message with my private key, tell you (in open text or in another message) how it was encrypted. Then you could decrypt the message with my public key, and if it becomes readable, you know it came from me.

This form of encryption is fairly computer intensive, so what sometimes is done is to encrypt a one-time "secret key" with RSA technology, then encrypt the rest of the message with the secret key, then encrypt my signature in the second fashion. You then reverse this process so if the message and the signature are readable, you and only you can read it and you are ensured that I sent the message.

OR

you can visit this link for more detailed explanation.

How do API Keys and Secret Keys work?

回答2:

You need two separate keys, one that tells them who you are, and the other one that proves you are who you say you are.

The "key" is your user ID, and the "secret" is your password. They just use the "key" and "secret" terms because that's how they've implemented it.

回答3:

Simple answer, if I understood it correctly...

If you use your API key for encryption, how will the service know who is contacting them? How will they decrypt that message?

You use API key to state who you are, this is what you are sending in plain text. The SECRET key you do not send to anyone. You simply use it for encryption. Then you send the encrypted message. You do not send the key that was used for encryption, that would defeat the purpose.

回答4:

There are answers explaining what the secret and (public) key is. It's a public-private key pair that they give confusing names to. But nobody says why the APIs require both, and many APIs only give you one secret! I've also never seen any API's docs explain why they have two keys, so the best I can do is speculate...

It's best to put only your public key in your request and sign the request locally with your private key; sending anything more shouldn't be needed. But some get away with just having the secret in the request. Ok, any good API will use some transport security like TLS (usually over HTTPS). But you're still exposing your private key to the server that way, increasing the risk of them somehow mishandling it (see: GitHub and Twitter's password logging bug recently discovered). And HTTPS is theoretically just as secure, but there are always implementation flaws out there.

But many – actually most it seems – APIs have you send both keys in requests since that's easier than making people do their own signatures; can't have pure cURL examples otherwise! In that case, it's pointless to have them separate. I guess the separate keys are just for in case they change the API later to take advantage of them. Or some have a client library that might do it the more secure way.