How do you manage api keys

Question

I'm looking at building an API and was considering oauth for managing access to the api, but what I'm doing is more of a b2b system allowing businesses to access data to incorporate into their sites. I won't have any b2c at the beginning.

So oauth doesn't seem like the right tool for me, I've been looking for sources regarding building a key based system, but haven't come across anything.

Is something available out there already? Is it best to just create a hash of some user submitted data or something like that?

Answer 1

I wouldn't just use user submitted data, as that can create a situation where API keys are guessable. Generally, I take some data that is generated by the user, and then combine it with some data that is relatively unique (ie, current system time) and hash that using SHA-1 or something, perhaps change the representation if I don't want it to obviously be a SHA-1 hash, and then use that as the key.

Answer 2

What you need is just something that uniquely identifies the user... Just use a UUID or maybe a hash of a UUID.

Just make sure that this ID is passed over a secure channel, if you are passing it over an insecure channel you may need to implement some method of securing the ID similar to HTTP digest auth.

Answer 3

Take a look at almost any Web 2.0 site/service. They all have varying degrees of doing auth and managing API keys. Flickr, Twitter, Github, etc.

Answer 4

Depending on requirements, in the world of web api's, giving your partners/developers an API key (identification) and requiring they sign the calls (authentication) is pretty standard. There are lots of ways to spec signatures. A pretty common one these days is; take all params of the call, a timestamp (+/- 5 min wiggle), a shared secret, and hash it using SHA-1 or MD5 (SHA-1 better).

You can either do implement this yourself or find a partner (there are a few) to do it for you.

Answer 5

The general approach being suggested here (to use a hash which includes an API key and the current time) are all good - certainly better than including a "password" in the message.

However, there is a crypto standard way of doing this "mung" operation called HMAC. Well worth looking at if you want something more standard / robust / safe.

Finally there is obviously the "gold standard" from security options - use a digital certificate to sign either all requests (can be computationally expensive) or use to sign an initial request which then generates a limitted use session key (e.g. one API only, with an expiry after 60 minutes).

Alternatively you could use 2-way SSL for the transport layer and simply trust that within the application / API.

Really depends how secure you want it... :]