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)

Improve this question
3

2 Answers 2

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

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 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).
So in the end, it sounds like it really just comes down to your own preference
@Obto indeed otherwise Yahoo, Google, Amazon all had the same best option.
True, luckily I found a great article on how amazon does their auth, so I'm going to go down that route.
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.

Improve this answer

1 Comment

@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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.