A 10,000-Year-Old Problem
Picture ancient Mesopotamia, around 8000 BCE. Life was booming. People were trading grain, livestock, and pottery between towns. The problem?
Once you handed off your goods, how could the other person prove the deal was real? There were no receipts, no emails, no “please find attached invoice.pdf.” Just a whole lot of trust issues and long donkey rides.
Imagine this:
A merchant named Naram is selling 20 sheep to a farmer named Ilu. Naram can’t accompany the delivery because, well, he’s busy selling more sheep (and arguing about barley prices). So he needs a way to prove that the person showing up at Ilu’s farm actually works for him.
What does he do?
He pulls out some clay tokens. Each little token stands for something: one sheep, one jar of oil, one very awkward favour. He counts out twenty tokens, representing twenty sheep, and drops them into a round clay envelope called a bulla.
But here’s the clever part: before sealing it up, Naram rolls his cylinder seal across the wet clay. Think of it as an ancient business logo carved into stone, maybe a lion, or his name in cuneiform, or a very dramatic sun symbol. Every seal was unique, like a signature.
Once sealed, that bulla became the Mesopotamian equivalent of a notarised contract. If the courier tried to sneak an extra sheep for himself or replace the envelope, the broken seal would give him away. When Ilu received the bulla, he’d look at the seal, nod, and say,
“Yep, that’s Naram’s fancy lion logo!!! I can trust this.”
And boom! The deal was done. No witnesses needed. No follow-up letters were written on clay. Just a simple, elegant system of trust through tokens and seals.
It worked so well that it spread everywhere. From tiny trade villages to the great city of Uruk, everyone was sealing their business in clay. In fact, archaeologists have found thousands of these bulla, some containing miniature shapes, cones, spheres, disks, each representing goods or numbers. Basically, ancient accounting, but with better aesthetics.
It’s kind of beautiful, really. Humans were inventing proof long before they even invented paper. They didn’t have math degrees or cybersecurity experts, yet they understood one timeless truth: you can’t build a civilisation without a way to prove who said what.
Fast forward 10,000 years, and not much has changed. The trust issues are still very much here. Turns out, ancient wisdom ages better than we do.
Scene Two: A Modern Library, The Same Ancient Wisdom
Imagine walking into your local library for the first time. You approach the front desk with your ID and documents, eager to start borrowing books. The librarian carefully verifies your identity, checks your address, and asks what type of membership you'd like—student, regular, or premium. After a few minutes of paperwork, they hand you a laminated membership card with the library's official seal embossed on it.
The card contains some key information:
- Your member ID
- Your membership type (Student/Regular/Premium)
- The expiration date
- The library's official seal
Fast forward to your next visit. You walk in, pick up a book, and head to the checkout counter. This time, the librarian doesn't ask for your ID or cross-reference a massive database. They simply glance at your membership card, verify the library seal is authentic, read your membership level, and immediately know whether you can borrow that advanced research book or if your student membership restricts you to the general collection.
This is exactly how JWT authentication works: a digital descendant of those ancient Mesopotamian tokens.
What is JWT?
JWT stands for JSON Web Token. It's a compact, self-contained way for securely transmitting information between parties as a JSON object. Like your library card or those ancient clay bullae, it contains all the necessary information about who you are and what you're allowed to do, cryptographically sealed for authenticity.
The JWT Authentication Flow: Library Edition
1. Registration & Login (Getting Your Library Card)
When you first register or log in to an application:
// User logs in with credentials
POST /api/login
{
"email": "john@example.com",
"password": "securePassword123"
}
The server acts like the librarian:
- Verifies your credentials against the database (checks your ID)
- Creates a JWT token containing your information (issues your library card)
- Signs it with a secret key (applies the library seal)
// Server creates and returns JWT
const jwt = require('jsonwebtoken');
const payload = {
userId: "12345",
email: "john@example.com",
role: "premium",
exp: Math.floor(Date.now() / 1000) + (60 * 60 * 24) // 24 hours
};
const token = jwt.sign(payload, process.env.SECRET_KEY);
// Returns to client
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
2. Subsequent Requests (Borrowing Books)
Every time you make a request to the server, you include your JWT token:
// Client sends request with JWT in header
GET /api/books/advanced-section
Headers: {
Authorization: "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
The server (librarian) simply:
- Checks if the seal (signature) is valid
- Reads the information from the card (decodes the token)
- Makes authorization decisions based on the membership type (role/permissions)
// Server middleware to verify JWT
const verifyToken = (req, res, next) => {
const token = req.headers.authorization?.split(' ')[1];
try {
// Verify the library seal is authentic
const decoded = jwt.verify(token, process.env.SECRET_KEY);
// Check membership level for this section
if (decoded.role === 'premium' || decoded.role === 'regular') {
req.user = decoded;
next(); // Allow access
} else {
res.status(403).json({ error: "Student members cannot access this section" });
}
} catch (error) {
res.status(401).json({ error: "Invalid or expired library card" });
}
};
3. No Database Lookup Needed
Just like the librarian doesn't need to check the main database every time you borrow a book—or how Mesopotamian merchants didn't need to send messengers back to verify every sealed envelope—the server doesn't need to query the database to verify your identity on every request. The JWT token is self-contained—it carries all the necessary information and proof of authenticity.
Anatomy of a JWT Token
A JWT consists of three parts, separated by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NSIsImVtYWlsIjoiam9obkBleGFtcGxlLmNvbSIsInJvbGUiOiJwcmVtaXVtIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
[Header].[Payload].[Signature]
1. Header (The Card Design)
{
"alg": "HS256",
"typ": "JWT"
}
Specifies the algorithm used for the signature.
2. Payload (Member Information)
{
"userId": "12345",
"email": "john@example.com",
"role": "premium",
"exp": 1735689600
}
Contains the claims—the information about the user and their permissions.
3. Signature (The Library Seal / Ancient Clay Seal)
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
Ensures the token hasn't been tampered with—only someone with the secret key (the library, or the merchant's unique cylinder seal) can create valid signatures.
From Clay to Code
JWT authentication is like a smart library card system, or perhaps more accurately, like the brilliant clay token system that helped build the first civilisations. It's efficient, fast, and scalable. While it has its limitations, particularly around token revocation, it's become the go-to solution for modern web applications, especially those with microservice architectures or mobile apps.
The concept has remained remarkably unchanged for 10,000 years: create a sealed token containing all necessary information, trust the seal, and conduct business without constant verification. From clay bullae to JSON Web Tokens, humans have understood the power of cryptographically sealed, self-contained authentication.
Next time you log into a website and don't need to re-authenticate with every action, remember: you're carrying a digital descendant of those ancient Mesopotamian clay tokens, sealed and trusted, that tells the server everything it needs to know about you, no database lookup required.
Top comments (0)