That's how we implement flaws in the process, around crypto libraries. The price of session-cache lookups is the price paid not to worry there is a serious undiscovered security flaw waiting for you around the corner.
Its a price you have to decide if its worth paying.
You're basically saying that if everything works as expected, then a signed cookie is no different than an opaque handle to server-side data. But it doesn't answer (IMHO) the point that there are more things that can go wrong with a signed cookie. IMHO, YMMV.
Here are some challenges that occurred to me in a signed-cookie approach:
1) How is the signing key generated? If it's the output of a weak PRNG, maybe it can be bruteforced?
2) Where is it stored? Hard-coded in source? Data file? Command line param?
3) Same signing key on multiple servers?
4) Do you regenerate the keys periodically?
5) What if a team member leaves. Do signing keys get regenerated?
With a DB-based approach, your session data just piggybacks on the server security infrasturcture that you would have built anyway.
You're not wrong, but note that the usual random-handle-to-server-side-state still needs good random (1) that is not correlated across servers (equivalent of 3; don't spin up VMs with the same data in the random pool!) And if you have long-lived admin sessions, you may need to think about (5) too, especially if the company does not own all the hardware that employees use.
if the crypto library is Nacl or keyczar, then yes, maybe, but there are still a hundred ways to fuck up. If one is calling the aes function from openssh directly then no, I am bound to get it wrong.
And the whole argument about having magically independant servers that do not need to do any secure callbacks is totally blown away by the standard approach to CSRF protection - you send a nonce to the client. If it comes back to an "independant" server, the nonce still has to be looked up and confirmed. maybe you can use cycled hashes but at some point, we need to get a server make a security callback. It just has to happen to keep things simple.
That's how we implement flaws in the process, around crypto libraries. The price of session-cache lookups is the price paid not to worry there is a serious undiscovered security flaw waiting for you around the corner.
Its a price you have to decide if its worth paying.