Why use an API key and secret?

Question

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

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

So why use two keys?

Edit: or is it an API key used to look for API secrecy?

Answer 1

Private key cryptography uses the same key to encode and subsequently decode the message. Thus, only those who know the “secret” can read the message.

RSA security is based on 2 corresponding keys. There is a public key for each user, and everyone can (should) know this. There is also a private key that only the user should know. A message encrypted with a public key can only be decrypted with a private key, and vice versa.

Thus, if I want to send you a message that only you can read, I will receive (from the network) your public key, encrypt the message with this key, and you are the only one 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 plain text or in another message) how it was encrypted. Then you can decrypt the message with my public key, and if it becomes readable, you know that it came from me.

This form of encryption is used quite intensively by a computer, so sometimes you need to encrypt a one-time "secret key" using RSA technology, then encrypt the rest of the message with a secret key, and then encrypt my signature in the second way. Then you completely modify this process so that if the message and signature are readable, you and only you can read it, and you are sure that I sent the message.

OR

You can visit this link for a more detailed explanation.

How do API keys and private keys work?

Answer 2

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

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

Answer 3

The simple answer, if I understood correctly ...

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

You use the API key to indicate who you are, this is what you send in plain text. You do not send the secret key to anyone . You just use this for encryption. Then you send an encrypted message. You do not send the key that was used for encryption, which would be contrary to the purpose.

Answer 4

There are answers explaining what a secret and (public) key is. This is a pair of public and private keys to which they give confusing names. But no one says why the APIs require either one, and many APIs only tell you one secret! I also never saw any API docs explain why they have two keys, so the best I can do is speculate ...

It is best to specify only your public key in the request and sign it locally using your private key; send anything else is not necessary. But for some, only the secret in the request gets away with it. Well, any good API will use some transport security such as TLS (usually via HTTPS). But you still expose your private key to the server in this way, increasing the risk that they will somehow deal with it incorrectly (see the recently discovered error registering passwords on GitHub and Twitter). And HTTPS is theoretically just as secure, but there are always implementation flaws.

But many - in fact most - APIs force you to send both keys in requests, as this is easier than forcing people to make their own signatures; otherwise there can be no pure cURL examples! In this case, it makes no sense to separate them. I believe that individual keys are only intended to change the API later to take advantage of them. Or some have a client library that can do this in a more secure way.