As a part of my very effective “get me out of bed asap” morning routine, it was 7 am and I was scrolling through LinkedIn.

And I saw this post…

It did get me out of bed in record time but I was roaming around feeling anger and cringe all day long (a side-effect of the routine, sometimes you get triggered).

In this blog post, I want to go point-by-point mentioned by bro in the above post and ACTUALLY try & explain the security, performance, and general usage concerns of JWTs.

Because, in all fairness, some of us who are a little bit too practical (including myself) don’t often get time to look at cryptography & security basics in our early years.

THEORY!

Now that I have captured your exceptionally low attention span, it’s time for the theory you so joyfully skipped!

Wa..wai...wait! wait!

Don’t close the tab! hear me out...

I promise, if you keep on, you’ll take away an “aha” moment from this post.

Unlike bro’s fake “yeah I felt it, it was amazing, now go to sleep” ‘aha’ this will actually be an “aha”

full of le- ground-shaking pleasure.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0OTM3ZWFhMC1lMzcyLTQ2OTItOTAxMS05MTA2ODliZjU0YzIiLCJpc3MiOiJhcHBsZS5jb20iLCJleHAiOjE3MjYzNDk0NDQsImlhdCI6MTcyNjM0MjI0NH0.zP46kmVHlANxt-dPJyA5WiRK_pX-EsYJWZnG2wd-h4U

Let’s start with this token.

What do you see? gibberish unga bunga 3-dot separated strings.

Taking each one out...

# 1 (HEADER)
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

# 2 (PAYLOAD)
eyJzdWIiOiI0OTM3ZWFhMC1lMzcyLTQ2OTItOTAxMS05MTA2ODliZjU0YzIiLCJpc3MiOiJhcHBsZS5jb20iLCJleHAiOjE3MjYzNDk0NDQsImlhdCI6MTcyNjM0MjI0NH0

# 3 (SIGNATURE)
zP46kmVHlANxt-dPJyA5WiRK_pX-EsYJWZnG2wd-h4U

First 2 segments of this token are base64 encoded strings.

Third segment is a combination of first 2 segments ENCRYPTED by a “secret key“

If you expand from base64 notation to human-readable form:

😯

Remember your friend JavaScript? It has a convenient atob function built-in to convert base64 encoded strings to normal ones, you can verify this right here in this tab.

Encoding/Decoding:
Converting data to/from a different format. (e.g. normal char to ascii or vice-versa)

Encrypting/Decrypting:
Converting data to/from an unreadable format with the purpose of hiding information.
Requires a “key“ to read the hidden information from ciphertext.

First segment contains the ENCRYPTION algorithm used in the signature & other metadata related to the token itself.

Second segment is the actual data you want to encode here, standard dictates you follow a specific naming convention and the data you encode should be a valid JSON string (see RFC7519).

But why base64? that demands its own blog post so here it is (not mine).

Let us now look at the 3rd segment in our token.

The string is not correctly encoded because it is NOT a base64 encoded string.

It is a “signature”, the part that makes the token tamper-proof (security brooo).

Here’s a graphic to make you understand this part:

HMACSHA256 is one of many encryption algorithms used with JWTs.

we need a “key“ that ENCRYPTS the concatenated result of HEADER (#1) & PAYLOAD (#2).

The result coming out from this encryption function is actual gibberish unga bunga, UNTIL WE HAVE THE KEY.

If the header or payload parts were to be tampered with in a token, the result of the encryption function would change and not match with the signature present in the token.

For these kinds of mismatches, JWT libraries throw errors because the token could’ve been tampered with.

Hence, any tampering with JWT will result in a broken token.

🤯

Now, what if someone got access to this “key” of yours? well… they can use this key to create tokens at their will to impersonate any user and generate valid signatures for those JWTs (panik).

This is why bro said:

🔑 Strong Secret Keys: Always make sure your secret key is tough to crack and stored safely.

You can use this website to learn more about a JWT: jwt.io

But, Why JWT?

Now that you know the basic anatomy of a JWT, let’s discuss the “why" behind them.

As you know JWTs are MAINLY used in authentication mechanisms.

Before JWTs, we used to assign a gibberish unga bunga string aka session ID to each user at login.

A session ID has meaning purely on the server side.

The server would create these session IDs on successful sign-ins, and store a mapping to the user’s ID and necessary metadata against them in a database like Redis for fast access.

However, due to the relatively high maintenance of session-based authentication, people have started using JWTs more.

Security Concerns

If you experience skill issues on a daily basis and you work on an application where users can post something that other users on the website can see.

It is highly likely, that there is an XSS vulnerability in your web app.

This means that someone could add a <script> tag to their posted content, remotely run it on everyone’s browsers when people view the content and take everything including users' JWT from LocalStorage, SessionStorage & Unsecured Cookies and send it to their own servers.

The attacker will have access to all the affected users’ accounts for however long you’ve set the expiry (exp) parameter in JWT.

This is the reason why it is generally advised to keep your JWTs short-lived because… skill issues.

To mitigate this issue completely, you can use HttpOnly cookies but that comes with its own set of possible attack vectors (e.g. CSRF attacks).

Finally, Coming to The LinkedIn Post

🛡️ Encrypt Your Tokens: I’ve started using CryptoJS to encrypt JWTs, which makes them way harder to mess with.

As we studied earlier in the theory section (bruh did you skip it again?)

JWTs are tamper-proof thanks to cryptography.

So bro is spittin’ unga bunga here…

⏳ Set Token Expiry: Keep tokens on a short leash with quick expiration times.

🔒 Always Use HTTPS: Never send tokens over plain HTTP—HTTPS all the way!

ChatGP- bro got this absolutely right here, good practices in general.

✔️ Validate Tokens Properly: Don’t just check if a token exists—make sure it’s legit on the server side.

Who here is rawdawgin’ them string split methods and atob functions to get the JSON? use a good library bro.

But yes, Gemin- bro got this one right too… technically. Don’t do that.

Concluding

I have a conspiracy.

Bro intentionally made a rather unpleasing post… and hear me out…

It worked.

People are engaging a lot in the comments, some PMs & HRs found his post helpful, while developers are correcting him.

People who didn’t scroll comments now think JWTs are bad.

He’s probably getting a lot of new connections though.

I mean, LinkedIn connections don’t mean **** but still, that ancient need for validation from the tribe is indeed dopamine-inducing unga bunga.

I myself fell into his trap and got so triggered that I decided to come out of my cave and write this post.

You can give me dopamine shots by liking this post.

Wanna discuss something? comments are always welcome!

Thanks for reading.