[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!