From Talking Drums to JSON Web Tokens

A few years ago I read James Gleick's The Information and couldn't stop thinking about the opening chapter on talking drums. The idea that ancient communication systems had to solve the same problems we solve today stuck with me so hard that I turned it into a talk for PHP com Rapadura, a developer community back in Ceará, Brazil, on May 18, 2019. The slides sat in a forgotten folder ever since, but the core idea aged well enough to deserve a proper write-up. So let's dust it off.

Before we get into JWTs, secure APIs, or anything that lives in a terminal, let's talk about fire, drums, and wax seals.

One Bit Is Enough (Until It Isn't)

In the 5th century BC, the Greeks used fire beacons to relay warnings across the Aegean. One signal, one meaning: the enemy is coming. One bit of information. No details about what kind of enemy, how many, or where they're headed. Just: something is wrong.

One bit is fast, unambiguous, and crosses hundreds of kilometers at the speed of light. This is load at its simplest: the actual content a message carries. But the moment you need to say anything richer (who is the enemy, where are they, how many) a single bit isn't enough. You need a bigger payload.

And a bigger payload brings bigger problems.

Talking Drums and the Problem of Ambiguity

The Yoruba people in what is now southwestern Nigeria solved this exact problem with talking drums. A drummer could encode full sentences like “make your feet return by the path they came” and transmit them across kilometers, village to village, faster than any runner.

The drums reproduced the tonal patterns of the Yoruba language, and many different words share the same tonal shape. Strip a word down to its tones alone and the same rhythm can mean several different things. A richer payload brought ambiguity baked into the medium itself.

The drummers' fix? Context. They padded messages with extra phrases, rhythmic patterns, and formulaic expressions that weren't needed for the meaning but narrowed the interpretation down to a single correct one. The extra information didn't protect against noise; it told the listener which of the many possible meanings was the right one. That's disambiguation: extra information injected on purpose so the receiver interprets the core message the way it was meant.

But Can You Trust It?

Neither fire beacons nor drums solved one more problem. Anyone within range can receive the message, but can you trust it hasn't been tampered with? Can you be sure it came from who you think it came from?

Royal courts figured this out centuries ago with wax seals. A king pressed his signet ring into hot wax on a letter. The seal didn't hide the content. Anyone could open and read the letter. What it guaranteed was that the message was authentic and hadn't been altered. Break the seal and the forgery is obvious. That's trustworthiness: not secrecy, but proof that the message is genuine.

So What Does JWT Have to Do with Any of This?

Fire beacons, talking drums, wax seals. Three different eras, three different problems, but the same three questions: what does the message carry, how does the receiver know what it means, and how do we know it's legit? When the web needed authentication, it had to answer them too.

A JWT is just a message. It carries its own data, no server-side lookup needed (load). Its header tells the receiver exactly how to interpret and verify the rest of the token, so the payload and signature aren't an ambiguous blob (disambiguation). And its signature guarantees that the content hasn't been tampered with. Anyone can read the token, but nobody can forge it (trustworthiness).

JWT Anatomy

A JWT is made of three parts separated by dots: header.payload.signature.

The Header

Declares the algorithm and token type. Without it, the payload and signature are an ambiguous blob that could be decoded or verified several different ways. The header removes that ambiguity by telling the receiver exactly how to interpret the rest. Same principle the drummers used: embed enough context in the message so only one interpretation is possible.

{
  "alg": "HS256",
  "typ": "JWT"
}

The Payload

The actual data the token carries. Like a talking drum that encodes the full sentence rather than a reference number to a sentence stored somewhere in a library, the token contains the information directly:

{
  "name": "Vidal Vasconcelos",
  "nickname": "vidalvasconcelos",
  "admin": true,
  "exp": 1700000000
}

The token itself is the source of truth. The server doesn't need to look anything up.

The Signature

A JWT does not guarantee secure communication. The payload is Base64-encoded, not encrypted, so anyone who intercepts the token can decode and read it. What JWT guarantees is that the information is trustworthy.

Change a single character in the header or payload and the signature breaks. The server can verify that the token is authentic and untampered using only the secret key. No database call, no session lookup. Same idea as the wax seal: it doesn't hide the letter, it proves who sent it.

Conclusion

We started with a fire on a hilltop. One bit, no detail, but enough to warn an entire coastline. Then the Yoruba drummers showed that richer messages need context so the receiver lands on the right meaning. And royal courts taught us that a seal doesn't hide a letter, it proves who wrote it.

JWT carries the same three ideas into web authentication. The header is the context that tells the receiver how to read the message. The payload is the content itself, traveling without needing a library to look it up. The signature is the seal. Not perfect: the content is readable by anyone, tokens live until they expire, and storing them carelessly opens the door to attacks. But the core principle holds. Put the intelligence in the message, not in the infrastructure around it.