Re: API Keys

On Thu, Nov 29, 2012 at 12:26:00PM +0100, Erlend Hamnaberg wrote:

> Is there anyone with experiences with implementing API Keys in their apis?
> 
> Putting the APIKey in the URI is obviously a bad idea as that leaks to every
> cache and intermediary. Including Apache logs.
> 
> So it must be a new header field. 

The WWW-Authenticate and Authorization headers exist for this very
purpose. In fact, RFC 2617 is designed to be extensible.

> The problem with APIKeys as such is that they are spoofable, unless they are
> crypographically protected somehow, so my question is:
> 
> What do you do in your api?

HTTP auth headers. There's really no need for anything else except maybe
in cases where it's not possible to use HTTP auth (such as embedding a
fragment of JavaScript in a page, such as with Google Analytics, in
which case you're not going to care much about spoofability anyway). For
all other cases, using the existing HTTP auth headers is the right way
to go because you *are* performing a form of auth with an API key.

> ps:
> I am thinking about writing up an internet draft for a new Api-Key header
> field.

You'd be better off proposing an alternative HTTP auth method, if
anything, where the client sends something like this (assuming the API
key is a UUID):

    Authorization: Key b67570be-3a22-11e2-8ca6-0015c55d83ee

Of course, that assumes a fixed key. If you wanted something more secure
and less liable to be spoofed, you'd end up with something similar to
Digest auth, so you might want to consider just using that unless you
can come up with something provably superior. Here's an example of an
alternative auth method:

    http://www.xml.com/pub/a/2003/12/17/dive.html

K.

-- 
Cíat Ó Gáibhtheacháin - [email protected] - http://stereochro.me/ - CF9F6473
True happiness comes from the joy of deeds well done,
                          the zest of creating things new.
    -- Antoine de Saint-Exupery