1

A typical API authentication usually rely on a pair of API ID + SECRET, my question is: if the API ID is unique and randomly generated and is considered strong enough (e.g. SHA512), why a SECRET is even needed?

What if, I created an API only need a API ID for authentication, what would be the drawback, especially in term of security?

Some people might say, it is easy to revoke the SECRET without changing API ID, but this does not sound since if you need to update the SECRET, you need to modify the config/source code as well.

Internally the API program can still have some unique ID to identify the client, but this information does not need to expose to the client code, just use a single ID is enough, right?

Actually I would considered using a single API ID is more secure - since when you change , it is more hard to identify the client (as there is no constant API ID)

Any conveats?

1 Answer 1

2

This is a lot like asking why we have both a username and a password for all our regular internet accounts, when arguably just a password is sufficient.

The first reason is actually contained in your question:

Actually I would considered using a single API ID is more secure - since when you change , it is more hard to identify the client (as there is no constant API ID)

That's the problem. Many services simply don't work if they can't remember who you are. Imagine if an e-mail provider "lost" all e-mail you'd ever sent or received every time you changed your password. Nobody would ever use them.

The second reason is that it's not more secure. Either way, the attacker only needs to figure out the secret in order to impersonate you. The presence of a non-secret does not automatically make the secret any less secure (assuming the method used to generate the secret and non-secret is cryptographically secure).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.