HTTP Basic Authentication vs Secret Key

4
votes

After building a fairly simple API, I started looking into authentication where the basic HTTP authentication over SSL with just a username/password combination may appear weak for someone using it, although various discussions on here suggest it should be fine.

As this is the case, I looked into the API's from similar solutions which provide their users with a user ID and an API Key instead. The problem is I don't see how this is any stronger at all. I assume the Key is still saved just the same as a password, where from my perspective it just looks like they are calling a password a key.

Example:

https://github.com/Arie/serveme/blob/master/spec/fixtures/vcr/HiperzServer/_restart/visits_the_Hiperz_restart_URL.yml

How does the &api_key=hiperz_api_key&gs_id=3873 args offer any further security than just a username password? I would definitely like to implement something stronger than just user/pass over basic HTTP authentication and provide the end user with some type of token/key to use for access, but I am failing to see the additional strength from such approaches.

3
phpauthenticationbasic-authenticationhttp-authenticationapi-key
Why not use digest authentication instead? – Anthony
I haven't come across this in all of my reading. Everything seems to suggest hashes, keys, secrets, etc. for true authentication security, where my head is spinning. Is digest more suitable than http basic auth? – David Anderson
if you want to authenticate at the start of the request rather than after the SSL connection is established, then yeah, you'd want digest. – Anthony
@Anthony, I don't think digest authentication is really a good alternative. It's based on an outdated hashing algorithm (MD5) and still requires the client to know the username and password. – MvdD

3 Answers

0
votes

Basic authentication is not recommended to protect APIs as I tried to explain in my answer here.

You are correct that using a client id and client secret is very similar to username and password authentication. The difference is that in the latter case you authenticate the user (a person), where in the former you authenticate the client (an application).

Whether you want to secure your API with a client id and secret depends on whether you can trust the client to keep them secret.

Either way, whether you have a trusted client, like a web application (living on a secured server) or an untrusted client like a JavaScript application or mobile application (living in the user's realm), token based authentication schemes (like OAuth2) provide a more secure way to protect your API than basic authentication. See my answer here for more information on the different ways to get tokens using OAuth 2.0

1
votes

Well, there is always 2 step authentication which can be done(either by sending a message to their phone .. or maybe giving each user a randomly generated code to fill). Also, you can create your own encryption mechanism and add it to the functionality of your webpages. For example, you can encrypt the data using your own made up encryption key and then when it reaches where you want it you only know the key so you can de-crypt it.

0
votes

I am learning API's at the moment as well. My understanding is that by using an API key you can have more control over what permissions the user has. Also the API key can be reinvoked at any time as well. Also it will save the customer time from inputing log in details on each use of the API. I am not sure if that answered your question or not.