16

I have found quite a few questions on this topic on SO, but couldn't find any answering this question:

Should I validate users with their username and password, or with an API key? And what are the pros and cons of each method.

I ask this because in my API, there are a couple of methods I'd like to lock down and verify that the user has access to some document or action. I'm a bit reluctant to authenticate by having the user send an HTTP AUTH header with their username and password because it feels unsecured and a bit more of a hassle for the user. On the other hand, though, if I use an API key, what's the point of the user ever creating a password? As they will no longer be using it to access features of the API.

UPDATE

If other readers of this are curious what I ended up using, I decided to copy how Amazon does their validation (good explanation here: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf)

OhadR
  • 8,276
  • 3
  • 47
  • 53
Obto
  • 1,377
  • 1
  • 20
  • 33

2 Answers2

7

you can use HTTP Authentication over SSL and that's secure enough. However it makes consumption of API a bit difficult as it requires the client library to support SSL. SSL can affect the performance too if you're expecting too many calls simultaneously.

API key option is just as insecure as HTTP Authentication without SSL. If you're not concerned with security then API Key is the easiest for consumers of the API.

Muhammad Hasan Khan
  • 34,648
  • 16
  • 88
  • 131
  • So if you go the API key route, is it even worth having the user make a password? Seems like the API key would get rid of most if not all of the purpose of having a password – Obto Sep 30 '11 at 06:38
  • @Obto username can be generated sequentially and password can be generated randomly. The more parts of auth credential; the longer and harder it is to crack the password. Its really a matter of taste. A longer API key with sequential and random parts or a separate username and a password. API Key is generally not human readable and auto generated (in which case password is redundant). – Muhammad Hasan Khan Sep 30 '11 at 06:44
  • So in the end, it sounds like it really just comes down to your own preference – Obto Sep 30 '11 at 06:56
  • @Obto indeed otherwise Yahoo, Google, Amazon all had the same best option. – Muhammad Hasan Khan Sep 30 '11 at 06:57
  • True, luckily I found a great article on how amazon does their auth, so I'm going to go down that route. – Obto Sep 30 '11 at 07:00
5

One good method is to have a login method, taking the username and password (hopefully over TLS). You give them an expiring token if they successfully auth; the rest of their API calls must contain this token to succeed.

Ivo
  • 5,378
  • 2
  • 18
  • 18
  • @Hasan Khan Note that the token doesn't *need* to be stored in shared state; it could simply be deterministically created using a server-side secret (e.g. date hashed with secret, hour hashed with secret, or timestamp reversibly encrypted). So you can use a stateful store which will probably scale to at least thousands of requests a second without issue and choose a more performant option if and when needed. – Eamon Nerbonne Dec 04 '12 at 14:52