Anyone with a 'large' web project written in Go want to chime in?
Perhaps you meant storing all session data is a bad idea versus just an ID? (If so, I'm with you)
If not - how would you identify an authenticated user? Or, how would you look up all their relevant session data in the DB?
A db based session, which really wouldn't be that hard to set up with github.com/gorilla/sessions, would just send a randomly generated session id to the client in a cookie, save the data in the db, then read that data back out of the db on the next request.
I'm curious: what do you consider particularly flawed? DB backed sessions with simple ID-storing cookies suffer many of the same problems, with the primary issue being that you can MitM the cookie and masquerade as another user if not served over HTTPS.
If you are just storing a user ID, email address and/or admin flag, the cookie is authenticated (to prevent modification of those values) and served over HTTPS (only, ever) then there isn't an immediate problem there. You also don't have to worry about hitting your DB for each request - Redis is real quick, but (without hard numbers) I don't expect that sending 1KB of cookie header data would be slower either.
As for "impossible to revoke" well if you have control over your server you can do whatever you like so this falls into the very not-at-all-impossible category. As a baseline as long as there is no personal information in the "secure cookie" there really is no issue at all.
A expiry date system is literally impossible to revoke without somehow maintaining a list of valid or invalid cookies, and by that point, you are hitting a database for each cookie.
So, one way, you don't have as much control, and you can't revoke a stolen cookie with potentially high level access rights. The other way, you are replicating a db backed session, and heaping complexity on top of it.
impossible to revoke without somehow maintaining a list of valid or invalid cookies
The way you've described things is how apps I'm familiar with do it (the latter way.) Thanks for clarifying.
You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.
> to prevent someone from trying to brute force ID generation
It's beautifully simple to give the client nothing more than a large random number to authenticate them.