Tomcat, for example, manages a user session where it stores the session ID in either a cookie or the URL - for browsers that don't have cookies enabled. This session then lets the server store arbitrary serialisable data which is available on all future requests, and it can be configured such that this session is shared between multiple servers if you are running load balanced sets. I've seen - and personally written - several applications where the authenticated user was simply stored in the session and the container managed it. It works, but if you don't get it set up right then the user finds themselves logged out when they hit a different server for their request.
Ah, yeah, seems to be pretty standard in Java stuff, which I avoided because of some experiences with Tomcat. ASP.NET uses a separate auth cookie from the session cookie. Even way back when I was doing PHP, it never occurred to me to lump the auth in with the session.
Sessions have made it on my list of top hated things, I wouldn't use them for anything. But, comparing auth cookie without session vs auth token, tokens look like the better option.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.