The development of software architecture has brought many new problems in handling user data.
Back when the internet was just getting started, applications could be run on a single server where all user requests were processed, including database queries.
Once a user logged in, their presence would be stored in the memory of the server.
But today, most applications cannot exist on a single server anymore.
In order to support millions of simultaneous users, systems will be distributed on hundreds of computers. This change has introduced a new problem for engineers to solve. How can another server identify a user that logs in if we cannot query the database at all times?
This is the state problem in distributed systems.
And the industry-standard solution to this problem is called the JSON Web Token or JWT.
It’s important for every developer to understand this topic because it’s crucial for building APIs and answering interview questions on system design.
The Engineering Challenge: State vs. Scale
To understand why JWTs are necessary, we must look at the limitations of the traditional method known as server-side sessions. The web uses HTTP, a protocol designed to be stateless. This means the server treats every request as a new interaction. It has no memory of previous requests. To address this issue, developers traditionally used sessions.
When a user logged in, the server created a record in its memory and assigned the user a Session ID. For every subsequent click or request, the user’s browser sent this ID back to the server. The server would look up the ID in its memory and confirm the user’s identity. However, this approach hits a bottleneck as soon as the application scales.
Imagine an application running on fifty servers. A user’s request goes to Server 1, where they log in. Server 1 stores their session data. The user’s next request might go to Server 2 because of a load balancer. Server 2 has no record of this user, so it rejects the request and forces the user to log in again.
To solve this issue, engineers have to create complex solutions. They might use “sticky sessions” to ensure a user always visits the same server, leading to uneven traffic distribution. Alternatively, they could set up a large, shared database just for session data, like Redis. This introduces a single point of failure and adds network delays to every API call. This limitation created the need for a stateless authentication method.
What is a JSON Web Token?
A JSON Web Token (RFC 7519) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.
The most important term here is self-contained.
In a session-based world, the “proof” of identity is stored on the server.
In a token-based world, the proof is stored inside the token itself.
The token contains the user’s ID and permissions.
The server does not need to look up a database to find out who the user is; it simply reads the token.
Because the token contains data, it must be trusted.
