[oxymoron]

I’ve frequently used the equivalent of HMAC_SHA512(long_secret,uid + ’|’ + timestamp) to generate a token on the server, which the client can retain and pass along requests, and can be verified on the server without persistence. I assume this is what you refer to as stateless authentication. While I agree that there are no real performance reasons to do so, it seems convenient to me every now and then. Is there a security reason to stop doing so?

[bb88]

Only if the long_secret was made public.

[LanceH]

How do you revoke access to that token?

[oxymoron]

Well, you don’t, so if that’s a requirement you’ve got to do it some other way.

[e12e]

You can rotate the secret to invalidate all tokens.

[tptacek]

No, you can't. That breaks all of your users, and so you'll rarely do it, even when it might be warranted. Don't engineer security countermeasures that you (a) might need to rely on and (b) will be afraid to use.

[e12e]

Good points. But for some types of apps, you might have groups of users (a company, team, municipality) that you might be able to afford the cost of "everyone log in again". Or you might be able to safely log out everyone after business hours (if in the same timezone).