Initial idea:
Yes, yes, hammer and nails are my everything. Automation of small tasks helps me remember the basics and fulfill my bucket of achievements for a day, at least, so I think. Whenever I have a straightforward problem, I use command line tools as much as possible to write simple automation for the future myself.
How hard can it be to decode and encode JWT? From here, the story begins. I found a simple command-line command that was supposed to work just fine:
jq -R 'split(".") | .[0],.[1] | @base64d | fromjson' <<< $(cat "${JWT}")
Source: https://prefetch.net/blog/2020/07/14/decoding-json-web-tokens-jwts-from-the-linux-command-line/
It all looked fine until it didn't work. Ouch-ouch! The command is for Linux. I use Mac; maybe this is an issue. :-/
The nature path for such "cluttered" and piped expressions is to dissemble them and assemble them again the way it works for me, possibly publish it to gist, which no one ever checks.
I started checking different articles to reassemble the command.
I figured out that base64 is not very friendly to pure string, so it is better to use echoing first with -n flag
echo -n "whatever" | base64 -d
split is a very delicate command that isn't very useful, so it is much easier to use sed with symbols substitution.
jq isn't installed by default on Mac. So it would be best if you did the following:
brew install jq
Below are some links I followed before I realized the issue isn't as elementary as it sounded at first glance.
https://www.howtogeek.com/435164/how-to-use-the-xargs-command-on-linux/
https://stackoverflow.com/questions/18234378/using-sed-to-split-a-string-with-a-delimiter
https://www.tecmint.com/xargs-command-examples/
Final solution :
As I dug further into the JWT rabbit hole, I felt there should be a more attractive solution.
I found a CLI that works amazingly on Mac: https://github.com/mike-engel/jwt-cli
brew install mike-engel/jwt-cli/jwt-cli
The usage was easy after installation:
jwt decode "my-jwt-token"
The most significant part is that it's popular, well-maintained, and will most likely work on any system due to its Rust language basis. Applauses to a great and easy-to-use tool from Mike Engel and contributors.
Final thoughts & Lessons learned-reminded:
This article describes precisely the use case that I wanted to remind everyone that we need to research tools and solutions before writing them ourselves. Through more thorough research, I could find a better tool faster and save myself time.
Also, I see more extensive adoption of Rust language due to its speed. Especially when it is regarding building CLI and development tooling. I feel this language will take over sooner or later, and I recommend it to everyone looking for a new challenge to try out Rust.
I also want to emphasize a great tool for Python Rust-based Ruff. This tool is significantly faster in linting, and even though it is in the early stages, it gets adoption by big open-source projects. https://github.com/charliermarsh/ruff