5

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.

David Anderson
  • 89
  • 2
  • 8
  • Why not use digest authentication instead? – Anthony Sep 11 '15 at 22:57
  • 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 Sep 11 '15 at 22:59
  • 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 Sep 11 '15 at 23:53
  • @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 Sep 13 '15 at 01:25

3 Answers3

1

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.

Abbas Baydoun
  • 11
  • 4
  • While I certainly appreciate 2 step auths, I am trying to create a system that isn't overly complicated for the user. Replicating that from similar solutions would be optimal, however they use API keys and I am not seeing where that differs from just having a password. – David Anderson Sep 11 '15 at 23:26
0

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.

Michael O Meara
  • 49
  • 10
  • The problem is I am still not really seeing the difference from a key and a password. It seems from every aspect that these are still really just the same thing unless I am missing something. – David Anderson Sep 11 '15 at 23:26
  • Heres my interpretation please correct me if I am wrong. If you use your log in username and password to access the API and if some one hacks the request then they could have your the full log in details and full access to your account. By using API keys if a hacker did hack into the request to the API they would only have an API key which has limited scope and could easily reinvoked. API keys can be created which limited how much a user can access in the API. – Michael O Meara Sep 11 '15 at 23:37
0

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

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
  • Thank you very much for the answer, this did clear it up a lot. The difference in a password vs key was my main confusion, where the way you explain it makes a lot more sense. – David Anderson Sep 14 '15 at 15:43