Since a few years ago, the most common and traditional method to do that was to store this data on the server using either a memory-based, disk-based, or external session manager. Each session can be retrieved using a unique ID that the client receives with the authentication response, usually inside a session cookie, that will be transmitted to the server on each subsequent request.

Here's a brief diagram showing the Session-Based Authentication Flow:

This is still a very common technique used by most web applications. There's nothing wrong with adopting this approach, as long as we are okay with its widely acknowledged downsides, such as the following:

• Memory issues: Whenever there are many authenticated users, the web server will consume more and more memory. Even if we use a file-based or external session provider, there will nonetheless be an intensive IO, TCP, or socket overhead.
• Scalability issues: Replicating a session provider in a scalable web farm might not be an easy task and will often lead to bottlenecks or wasted resources.
• Cross-domain issues: Session cookies behave just like standard cookies, so they cannot be easily shared among different origins/domains. These kinds of problems can often be solved with some workarounds, yet they will often lead to insecure scenarios to make things work.
• Security issues: There is a wide and detailed literature of security-related issues involving sessions and session cookies: XSS attacks, cross-site request forgery, and a number of other threats that won't be covered here for the sake of simplicity. Most of them can be mitigated by some countermeasures, yet they can be difficult to handle for first-hand developers.

As these issues arose over the years, there's no doubt that most analysts and developers put effort into figuring out different approaches.