Get my system design playbook for FREE on newsletter signup:
This post outlines how JSON Web Token works. You will find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Note: This post is based on my research and may differ from real-world implementation.
Once upon a time, there lived a software engineering student named Keiko.
Although extremely bright, she never worked on any real-world projects.
So she struggled with coding.
Until one day, when she decided to build a weather app.
And shared it with her friends.
Yet she had no idea how user authorization worked.
HTTP is stateless; it means each request should include the necessary information.
And her friends had to enter their username and password on each page for authorization.
It was frustrating.
So she set up a session store on the server:
It tracks user sessions and gives a session ID to the client.
And the client includes the session ID with each request header.
The server then checks the session store to identify the client for access.
Although it temporarily solved the authorization problem, there were newer issues.
Her tiny app became popular among university students across the world.
So she had to install more servers and put them behind a load balancer.
But it became difficult to manage sessions with many servers.
Because the load balancer might route requests from a user to different servers.
So she set up sticky sessions. It means routing requests from a specific user to the same server using their user ID or IP address.
Yet it doesn’t scale well because of stateful servers and uneven load distribution.
So she installed a shared session store. It keeps session data separate in a central store.
A shared session store allows stateless servers. But introduces coupling and becomes a single point of failure.
So she set up JSON Web Token (JWT) for authorization.
Think of JWT as a badge to enter a building. A user gets the badge from the front desk after verification. Then they can access authorized rooms without verifying their identity again.
The server doesn’t store session information with JWT. Instead JWT includes necessary authorization information, and the server checks the JWT on each request.
Imagine authentication as permission to enter a building. And authorization as the permission to enter specific rooms of the building.
Onward.
Linear: Issue tracking without the noise - Sponsor
Simple, robust, and blazingly fast.
Linear is purpose-built for engineers:
Create issues in seconds
Automate your Git workflows
Navigate your entire workflow with keyboard shortcuts
Less grunt work, less context switching. More focus, more flow. See for yourself with $250 off.
How JWT Works
Let’s dive in:
1. JWT Structure
JWT doesn’t look like a JSON object, but a set of characters.
It has 3 parts:
Header: It specifies the signing algorithm, such as RSA or HMAC
Payload: It contains data and expiry time
Signature: It shows the payload’s authenticity
The payload is base64url encoded for compactness and ease of transmission across networks.
The server combines the header and payload with a secret key. Then it performs the signing algorithm to create the signature. Only the server has access to the secret key.
The server recomputes the signature using the header and payload each time it receives a JWT. Thus checking if the payload was modified.
Ready for the best part?
2. JWT Workflow
Here’s the JWT authorization workflow:
The user enters the name and password for authentication
The server creates a JWT using the authorization information
The server signs the JWT and gives it to the client
The client includes JWT in HTTP headers for authorization
The server allows a request only if the signature on the JWT is valid.
3. JWT Security
There’s a risk of JWT getting stolen and used for false authorization.
Here are some ways to avoid this problem:
Send JWT over HTTPS for security
Set an expiry time on the JWT to limit the damage
Assign minimum roles to JWT to reduce the damage
Yet there’s no way to invalidate a stolen JWT. A workaround is to include the stolen JWT in a denial list on the server.
JWT remains a popular authorization mechanism on the internet and in microservices architecture. It makes it easier to transfer information across services.
Solving a problem makes the next one easier.
So build projects. And join my free newsletter to elevate your system design skills.
Subscribe to get simplified case studies delivered straight to your inbox:
Want to advertise in this newsletter? 📰
If your company wants to reach a 150K+ tech audience, advertise with me.
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
TL;DR 🕰️
You can find a summary of the article here. Consider a repost if you find it helpful.
The biggest thing about JWTs: since they’re stateless, they scale really well.
No need for the server to remember who you are between requests.
Nice read, Neo!
It's also important to mention that even if we try to embed some more information in the token, it will get rejected from the Server because it won't be valid.
Great article, Neo!