- Level Up Coding
- Posts
- LUC #61: Session Management Demystified: Cookies, Tokens, and Security
LUC #61: Session Management Demystified: Cookies, Tokens, and Security
Plus, how decide which database type, API gateway vs load balancer, and how connection pooling works
This week’s issue brings you:
How Session Management Powers Secure Interactions
API Gateway vs Load Balancer — What's the Difference? (Recap)
SQL, NoSQL, or Something Else — How Do You Decide Which Database? (Recap)
READ TIME: 4 MINUTES
Thank you to our partners who keep this newsletter free to the reader:
How can we automate the health and performance of our APIs?
Postman Monitors is a great way to do this. Learn more about it here!
How Session Management Powers Secure Interactions
Imagine having to reintroduce yourself every time you speak to someone.
Tiresome, isn't it?
Our applications experience the same dilemma. They need a way to recognize the users interacting with them.
This is where session management steps in.
Session Management is the process of securely handling multiple requests to a web-based application from a single user or entity.
Essentially, it’s the process of recognizing users across multiple requests on web applications, ensuring that interactions can flow without constant reintroductions.
Why is it Important?
There are two primary reasons that session management is a fundamental component of web applications; maintaining user state, and security.
HTTP is a stateless protocol, meaning each request from a client to a server is treated as a new, standalone request with no memory of previous interactions.
Session management provides a way to retain user-specific data across multiple requests.
As for security, proper session management ensures that the user is who they say they are throughout the session's lifespan, providing protection against unauthorized access, CSRF attacks, session hijacking, and more.
The Mechanics Behind the Scenes
There are several techniques for implementing session management, however, some are more secure than others.
Today, we'll be covering the three most prominent techniques throughout the industry, all of which are considered to be highly secure approaches.
Cookies are small pieces of data sent from a server and stored on a user's web browser while the user is browsing. They are the most common session management tool.
Upon a successful login, the server sends a unique session ID in a cookie. With each subsequent request, the browser sends this cookie, reminding the server that they've met before.
Token-based Management
With the rise of single page applications (SPAs), mobile apps, and distributed systems where maintaining state on the server can be challenging and inefficient, modern applications have embraced tokens.
Post-login, the server dispatches a signed token, often in the form of a JSON Web Token (JWT), to the client.
The client then stores the token, often in a cookie.
The token then accompanies each request, usually in the HTTP headers, acting as proof of the user's identity.
Server-side Management
On the other side of the coin, we have server-side session management.
It’s a more traditional approach where the session state is maintained on the server. Whether in databases, in-memory storages, or file systems, session data resides securely server-side.
The client, in this scenario, only holds a unique identifier, rather than the session state being stored on the client.
Server-side management has been the standard approach for many years and is still highly prevalent, particularly in legacy systems and certain types of applications.
However, with the architectural trends of the past decade, token-based management has become the most common approach in modern applications and systems.
Session management, though often operating in the background, stands as a cornerstone in ensuring the fluidity and security of our applications and systems. Proper session management not only plays a role in creating smooth user experiences. In an era marked by cyber threats, it’s a major pillar of keeping our applications and systems secure.
API Gateway vs Load Balancer — What's the Difference? (Recap)
API gateways focus on request management and microservice communication, while Load balancers focus on traffic distribution and server load management.
API gateways operate at the application layer (L7), while Load balancers can operate at both transport (L4) or application (L7) layers.
API gateways offer features like routing, rate limiting, authentication, service discovery, parameter validation, circuit breakers, and more, while Load balancers handle traffic distribution.
API gateways are ideal for microservice architectures needing centralized API management, while Load balancers are essential for applications requiring high availability, distributing traffic across multiple servers.
What is Connection Pooling, and How Does it Work?)
Handling API requests often involves querying the database. Creating a new connection for each API call introduces unnecessary overhead.
Connection pooling mitigates this by reusing existing connections and reducing the overhead of establishing and closing connections.
This leads to faster response times and reduced resource consumption, making connection pooling a key technique for optimizing resource management and enhancing application performance.
So how does it work?
Connection pooling maintains a cache of reusable database connections, avoiding the need to create a new one each time.
When a connection is needed, an available connection from the pool is used, and when the task is completed, the connection is returned to the pool for future use.
See the full post here for a more detailed explanation, including key components and best practices.
SQL, NoSQL, or Something Else — How Do You Decide Which Database? (Recap)
The performance of your application can suffer if you choose the incorrect database type, and going back on a bad choice can be time-consuming and expensive.
There are several types of databases, each designed and optimized for specific use cases; relational, document, graph, columnar, time-based, key-value, and time-series, to name a few.
Considerations that should be made to choose the optimal database for your use case:
How structured is your data?
How often will the schema change?
What type of queries do you need to run?
How large is your dataset and do you expect it to grow?
How large is each record?
What is the nature of the operations you need to run? Is it read-heavy or write-heavy?
Which databases do your team have experience with?
That wraps up this week’s issue of Level Up Coding’s newsletter!
Join us again next week where we’ll explore and visually distill more important engineering concepts.