views:

201

answers:

2

I have been working with APIs and I've always wondered why you have to use a key and a secret?

Why do you need two types of authentication?

A: 

The secret is often going to be in case you forget your key, so you can be questioned on secrets to see if you are the correct person.

Otherwise, if you lose your key or password you will not be able to get it replaced.

James Black
Should clarify that the answer to the secret is encoded in MD5 format, which is not backward decodable. Therefore, when you give your answer to the API supplier they will encode that answer in MD5 format and compare that with the secret, if they match, it's all good.
jakeisonline
For many ideas in authentication you should have something you know and something you have. You have a key, perhaps as a certificate, and you know a secret, so they can verify that if you have both, you are whom you state you are. This is how ATMs work, you have a card and know a PIN.
James Black
+1  A: 

When a server receives an API call, it needs to know two things: Who is making the call, and whether or not the call is legitimate.

If you just had one item ("key"), and included it with every call, it would answer both questions. Based on the "key" the server knows who you are, and because only you know the key it proves that the call is actually coming from you. But including the key with every call is bad security practice: if someone can read even one of your messages in transit, your key is compromised, and someone can pretend to be you. So unless you're using HTTPS, this approach doesn't work.

Instead, you can include a digital signature with every call, signed with some "secret" number. (The "secret" number itself is not sent). If an attacker manages to read your message, they won't be able to figure out this "secret" number from the signature. (This is how digital signatures work: they are one-way). But this doesn't solve the identification question:

But in the latter case, how does the server know who is making the call? It could try to verify the signature against the "secret" of every single user, but of course this would be very time-consuming.

So, here's what we do: Send both a "key" (that identifies the user), and a signature created using the "secret" number (that proves that the message is legitimate). The server looks up the user based on the key, and then validates the signature using that user's "secret" number.

This is a bit like when you write a check: It has an account number on it (to identify you) and your signature (to prove that you're you). Having just the account number wouldn't prove that you actually wrote the check. Having just the signature without the account number would force the bank to compare your check against all of its signatures for all of its accounts, which would obviously be inefficient.

Eugene Osovetsky
its pretty explanatory but still a little confusing as to what do you mean by signing with some secret number??
OrangeRind