Pedantically, a "signature" is the product of a public key signature algorithm. It's what you use when you have multiple and/or anonymous verifiers.

An authenticator is the product of an authentication algorithm, which can be as simple as a keyed SHA-3 hash (a hash over the data to be authenticated and a key known only to the verifier).

Session tokens virtually never use signatures. The only party that needs to verify them is the serverside of the application that generates them; they're opaque to clients.

So you're assuming the session tokens are authenticated with a shared key. I guess that makes sense from a perf standpoint. It seems iffy from an isolation standpoint, though. I wouldn't think you would want every server holding effectively global auth keys.

Edit: I guess this is actually a good case for the 2CH described here. The long-session cookie could be cryptographically signed, while the short-session cookie could be authenticated with a shared key that gets rotated frequently so that a leak of the key cannot cause a long-term compromise.

I don't know what you mean by "isolation", but virtually every mainstream system that stores secrets in tokens uses MAC constructions, not signatures. Signatures are much more complicated and dangerous.

Don't ever use public-key crypto unless you absolutely need it.

Isolation meaning that every web server cannot issue authenticated cookies for arbitrary users. I'm clearly not a security expert but that seems to greatly increase the damage scale of a single web server breach.

Also, how would you store a secret in a token without encryption? Or was that just a misstatement?

In practice, you do one of three things:

1. You encrypt and then authenticate data, such as user profile information, so that clients can neither read nor alter it. This doesn't involve public-key encryption.

2. You authenticate data, but don't encrypt it, because it isn't secret but must not be changed; this is what you'd do if the only semantic value being passed in your token as UUID, for instance.

3. You do neither of these things, and instead generate cryptographically random tokens of sufficient length that they can't be guessed, and then use those tokens as database lookup keys.

All three of these things are lightning fast on any decent processor, including the one on your phone.

You are very likely to cost yourself more security than you gain by trying to do anything more complicated than one of these three things. Again: don't ever use public-key crypto unless you really need it.

Thanks. Sounds like I need to do some more research on this. This isn't how I thought this was generally implemented by the big players, but I've not worked closely on auth either.

I guess for 2 and 3, you handle revocation by just deleting the relevant row or flagging a "revoked" column. For 1, add a unique id that you can add to a revocation list? Are there better/more typical ways to do this?

Revocation is a problem for encrypted tokens; it's a downside to the approach. The common solutions aren't particularly elegant.

A fourth option would be just like option 3, except you only use part of the DB token in the lookup and compare the remainder in constant-time if and only if the record exists (if you're worried about the database lookup leaking a valid authentication token).

Agreed that public key crypto isn't really appropriate here.

He means that the auth key has to be shared between N servers, ie you can't have a scenario where a server can verify all the others' signatures but can only issue its own.

This might help: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...