[jpalomaki]

Why not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries.

I would consider more complicated solutions only if you first come to conclusion that these simple things are not fit for the purpose.

True that some fancy token based solution may reduce database load, but if the API is doing something useful then that one primary key lookup and potentially the password hashing won't be a show stopper. Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly. With API key you can just change the key and requests stop immediately (with MVP product this might be an issue, since maybe you have decided to add rate limits etc later).

[alex_duf]

I would agree, always start simple - unless you manipulate sensitive data - a shared secret is a good place to start (api-key or basic/digest auth)

You can always introduce other forms of authentication later. I have a slight preference for basic/digest auth as the secret isn't part of the URL, and therefore not cached/logged by any network equipment.

[webster23]

The api-key does not need to be part of the URL, you can also put it in the Authorization header.

edit: typo

[Scarbutt]

Why not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries.

Does basic auth works if the client is a browser and you want to have a nice login screen?

[iEchoic]

> Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly.

You can solve this with a token/user blacklist. There are desirable (and undesirable) characteristics of using a blacklist instead of a whitelist, but you don't lose this capability.

[mattbroekhuis]

How do you share your blacklist across servers

[DanHulton]

The same way you share any of your other data across servers. Save it in a DB or Redis instance that all your servers can reach.

[eropple]

At which point you're hitting it on every request and since it'll be a nice, fast, indexed database lookup you might as well just use session tokens instead of a back-assward blacklist.

Do the simplest thing that will work.

[iEchoic]

As I mentioned, blacklists have different characteristics, some of which are desirable. A blacklist of tokens is (for the vast majority of use cases) orders of magnitude smaller than a whitelist, which means they can often be replicated into memory for in-memory lookups on the webserver.

This is a complex distributed systems topic, and there are applications for both.

[eropple]

There are cases where a blacklist totally makes sense, I will agree with you on that.

"I can access this thing" are totally not that for the 99.9% case. Do the simplest thing that will work--and the simplest thing so very rarely involves public-key cryptography!

[comradesmith]

HTTP Basic authentication should never be used, it is very vulnerable to traffic analysis attacks. HTTP Digest authentication however, would be a perfectly fine solution.

[dozzie]

How so? Over SSL? (Note that you should never call anything requiring authentication/authorization over plain HTTP.)

[comradesmith]

A quick Google suggests you're right, as in either case you must run SSL/TLS.

Appypolylogies.