API keys and authentication

[Kevin Ellis]

When implementing an API that always requires users to authenticate, is there still value in issuing and using API keys?

On the one hand I can see that having all API logging done against KEYS would give a standard way for both anonymous and authenticated users, but then again it seems overkill when we have usernames to identify by.

I was wondering how others handle authenticated users.

Thanks,
Kev

[landlessness]

one reason to issue API keys is to track the developers who are using the API to build the apps that people use.

it's one of the key aspects of going from a direct to an indirect dev model.

[Kevin Ellis]

So an API key is issued to the app developer and not the users of the app.
In these cases we'd see many different users accessing our API with the same API key?

[landlessness]

yes. that's the idea.

[Kevin Ellis]

Got it, thanks.
Kev

[Jack Repenning]

On May 11, 2012, at 7:53 AM, landlessness wrote:

one reason to issue API keys is to track the developers who are using the API to build the apps that people use.

We have also discussed, though not yet ever had to actually implement, the possibility of turning off all access by a given API key. The notion would be that a major bug of some sort was discovered in that developer's application (say, a runaway "DOS-like" flooding). 

Jack Repenning

Outside of a dog, a book is a man's best friend.

Inside of a dog, it's too dark to read.

-- Groucho Marx

[Kevin Ellis]

That's a very good point. We might need to apply different throttling rates to some developers.

[Jeff Schmidt]

The application I'm working on is currently not free. So, the API
key (or OAuth client credentials in our case) is issued by us to
paying tenants. If that relationship changes, then the credentials
are disabled, removed etc.

These credentials are used to acquire tokens on behalf of user agents,
or even the tenant's own server systems for access. The token can only
be issued by the tenant (assuming they are the only ones possessing
the credentials). The token provided by the client identifies the
tenant, which is useful for attributing usage (including rate limits)
and indicating which content is available to the client. Tenants
upload content that is associated with our content. So, a valid token
signifies authorization for the client to access some set of API
methods, our content (subject to tenant specific rules), and the
tenant's content.

We don't yet have any end user identity or data present within our
application. It's possible we never will, since user-ness is a notion
of the tenant applications using our service.

Cheers,

Jeff