Still learning about this, but couldn't you:
1. Sign a cookie.
2. Store revocations in a database (remove after session expiry time).
3. Use a distributed bloom filter to avoid db hits for every request.
?
Yes you could, but you still end up with this dependence on a lookup when you store revocations.
Once you do that you lose the stateless benefit of cryptographically signing the object, and at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.
A table of unexpected revocations will be smaller and less write-intensive than a full table of sessions. Should be by a very large margin. And eventual consistency is fine.
So that could be the difference between whatever you're using for storage, and a tiny, fully replicated in-memory structure. Depending on your overall scale, of course.
> at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.
Only if the collision of lookup IDs (accidental or malicious) is effectively impossible. If it's possible to generate a collision, then you've thrown away your security.
This would also effectively give every server the ability to issue auth tokens (and mutate them in the DB), which is not a great choice if you care about security. But if you're handing out unsigned lookup IDs, you probably don't.
What purpose could signing a lookup ID possibly serve? Are you worried that someone might correctly guess the 128 bytes of the identifier and hoping they won't guess the 32 of the signature?
And actually, yes, if I were using 128 byte identifiers for some reason, I would still be concerned about malicious parties being able to cause collisions. Securely generating random numbers does not seem easier than authenticating.
Just to chime in since I'm the OP of this subcomment.
Generating 128 byte identifiers is ridiculously overkill. I can safely say if you generate 128 byte identifiers securely, the earth will cease to exist before a collision is found.
You would be safe generating cryptographically secure 128 bit identifiers and looking them up. It is trivial to generate IDs that will not collide.
Depends entirely on how well you generate your IDs. Yes, if you generate cryptographically strong IDs of sufficient length, then you don't need to sign.
Signing avoids the need to generate secure IDs, though, and can also avoid hitting to the DB for expired tokens. (Load from expired tokens is probably not a major concern, though.)
Once you do that you lose the stateless benefit of cryptographically signing the object, and at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.