When I was enforced to make my own JWT library

Back in the day when I was just playing around with web technology, I did not think that much about how things work or the concept behind it. Most of them already provided by random packages on the internet. Most parts I worked on was just boring call after call to those packages to match the business logic. Including the auth implementation such as JWT. All I knew about JWT was just about what it provides.

Until when I worked on an IoT project. We decided to build ESP8266 based board because it has more memory & computing power compared to other microcontroller while having relatively the same cost in terms of money and power consumption. We were not sure what kind of data transmission we will have. Because the sensor module can be deployed in various place and it may requires different type of transmission module & protocol. But we still needed to make sure that data transmitted was coming from authorized device.

That’s when I thought about implementing JWT. I can put the data inside the token and verify its authenticity later in the server. Because I was coding in C++ (with Arduino framework), I needed JWT library for it. So I searched across platformio registry, googling around, filtering github repos, and found nothing about JWT for microcontroller (at that time).

So I needed to rethink about it and consider making my own library to generate JWT. Because the program for data sink in server was already done using that for authentication. It would be a waste of time if I had to rework on server too. Then I tried reading RFC 7519. Turns out that it was not as complicating as I thought.

JSON Web Token consists of three segments divided by dot symbol. First segment is just JOSE header containing at least type of the token and algorithm it uses. Second segment is payload which we want to send. Both first segment and second segment must be formatted in JSON before encoded into URL safe base 64. Third segment contains the hash of segment 1 & 2 joined with dot symbol. We need to sign that hash with a key before encoding it to URL safe base 64 string.

We did not need to support all algorithm right, so ES256 was picked. It’s because we want to allow any sensor module owner to contribute to the data sink. They can just give us the public key to our server to verify the token. While the owner can keep the private key for themselves and the sensor module. ECC key is also shorter and requires less memory/cpu compared to other such as RSA with the same security level. It’s perfect for ESP8266 I mentioned earlier.

The rest was just coding (I pushed the code to this repo: micro-coder ). When I took a look again at the code, I realized how small it was (source line of code). If I had decided to rework on data sink program, it would be real waste of time. This also might be better than using library (if there was one). Because libraries usually intended to support all algorithm, resulting in larger binary and took up more ROM of the microcontroller that we did not want.

Coding was not even a matter to think too much anymore since that time, I guess I was allowed to call myself Engineer then 🙃