JWTs Explained: From Basics to Security 🔐

JWTs (Json Web Tokens) is basically a digital token that allows a server to identify an authenticated user without asking for the username and password on every request.

Example:-

1. You login into website: Username + Password → Server
2. The sever verifies your credentials and gives you a JWT token: xxx.yyy.zzz
3. Now, instand of sending your password with every request, the browser sends the JWT token: Browser → JWT → Server
4. The sever verifies the token and understands: " Yes, this is an authenticated user."

JWT itself doesn't automatically mean that the user is authenticated. The server must properly validate the token, including its signature and relevant claims.

JWTs

A JWT normally consists of 3 parts:

Header.Payload.Signature

• Header → Contains information about the token, such as the signing algorithm.
• Payload → Contains infomation or claims about the user/data.
• Signature → Helps verify that the token has not been modified or tamperd with.

Example: xxx.yyy.zzz

• xxx ← Header
• yyy ← Paylaod
• zzz ← Signature

Important: The payload of a normal JWT is not encrypted. It is Base64URL encoded, which mean anyone who has the token can decoded and read the payload. So, never put passwords or other sensitive information inside the JWT payload.

In one line:

🔐 JWT is a token used to securely carry information and prove a user's identity between a client and server.

JWT vs JWS vs JWE

1. JWT defines:

JWT mainly defines a ways to represent "claims" as a JSON object. Example payloads

{
 "user": "tanvexar",
 "role": "admin",
}

{
 "user": "tanvexar",
 "role": "admin",
}

The JWT specification basically defines how this information (claims) can be represented and carried as a token.

But JWT itself does not define how the information should be signed or encrypted.

That's where JWS and JWE come in:

• JWS → Defines how the content can be digitally signed.
• JWE → Defines how the content can be encrypted.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

2. JWS defines🔏:

JWS = JSON Web Signature

JWS job :

Digitally sign the content so that its integrity and authenticity can be verified.

Therefore, you commonly see a token like this:

xxxxx.yyyyyy.zzzzz ← This is generally signed JWT

Structure:

Header.Payload.Signature

The server verifies the signature to check whether the signed parts of the token have been modified or tampered with.

Note:

" Signature ≠ t confidetiality"

The signature's purpose is not confidentiality.

The payload of a JWS token is normally readable because it's encoded, not encrypted.

So:

JWS → integrity + autheticity 🔏 JWE → Confidentiality through encryption 🔐

In simple words:

• JWS: " Has someone modified this date, and can i verify who signed it?"
• JWE: "Can someone who doesn't have the required key read this data?"

Note: JWT ka payload readable hona apne app mein vulnerability nhi hai, because JWS mein payload encoded hota hai, encrypted nhi. Concern tab hai jab payload mein sensitive information unnecessarily expose ho rhi ho.

Remember this: "Readable ≠ Vulnerable Sensitive data exposure = Concern 🔐"

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

3. JWE Defines 🔐:

JWE = JSON Web Encryption

Purpose is:

Encryption of the token content.

In a normal JWS:

Content → encoded → readable after decoding

In JWE:

Content → encrypted → cann't simply be read without the required key.

So:

JWS → Signed 🔏 JWE → Encrypted 🔐

"In a line: JWS: Data ko modify/tamper krna, detect krna mein help krta hai. JWE: Data ko read krne se protect krta hai.

JWT = claims representaion JWS = signing JWE = encryption

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Simple easy analogy

Think you have a letter:

JWT = Standard format of letter

Now you have two options:

A. JWS: Letter ko seal/sign kr diya → pta chal skta hai ki letter tamper hua ya nhi.

B. JWE: Letter ko lock/encrypt kr diya → unauthorized person can't read content.

So "JWT is usually either JWS or JWE" meaning?

In partical words when people says JWT, who usually talk about JWS-based JWT.

Therefor: "JWT ├── JWS → signed JWT ← most commonly encountered └── JWE → encrypted JWT"

Important nuance: JWT, JWS AND JWE technically is not interchangeable terms. JWT is the claims/token concept, while JWS/JWE are standardized mechanisms for securing/serializing that content.

Note: JWT → What is being represented? JWS → How is it signed/protected from modification? JWE → Hpw is it encrypted/protected form being read? When ypu commonly see a three-part token like "eyJ……eyJ…." in Burp Suite, there is a good chance you are looking at a JWS-based JWT.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

JWT Attacks

JWT attacks are attacks where an attacker manipulates or abuses the way a server handles JWTs to bypass authenticaton, authorization, or other security controls.

JWTs are commonly used for:

• Authentication → who's the user?
• Session management → Is the user's session still valid?
• Acess control/ Authorization → what is the user allowed to access?

If there is a flaw in JWT handlind, an attacker may potentially make the server believe:

" I am a different user."

For example:

Normal user
  ↓
 JWT
  ↓
server
  ↓
Normal access

Normal user
  ↓
 JWT
  ↓
server
  ↓
Normal access

An attacker may try to manipulate or abuse the JWT:

Attacker
  ↓
Modified JWT
  ↓
Server
  ↓
Server incorrectly trusts it
  ↓
Unauthorized access

Attacker
  ↓
Modified JWT
  ↓
Server
  ↓
Server incorrectly trusts it
  ↓
Unauthorized access

The attacker tries to convince the server that they are using another user's identity.

Note:

when you see a JWT, don't immediately think:

"I found a JWT, now i need to attack it."

instand, ask:

"what does ther server trust in this JWT?"

Then investigate:

Token → Claims → Signature → Algoritm → Validation → Authorization

This helps you understand where the trust exists and where the implementation might be weak.

Impact of JWT Attacks?

The impact of JWT attacks can be very serious.

If an attacker is able to create or modify a valid JWT with values they control, they may be able to:

• Escalate their privileges → For example, a normal user may become an admin.
• Impersonate another user → The attacker may be able to act as another user.
• Access unauthorized resources → In servers cases, an attacker may gain access to resources they should not have access to.
• Take over accounts → In severe cases, an attacker may gain full control over another user's account.

In simple words:

If the server blindly trusts attacker-controlled values inside a JWT, the attacker may be able to turn a normal user into an admin or impersonate another user.

🧠 My perspective

When testing JWTs, don't only ask:

"__Can i modify the token?"

Ask:

"What happens if the server trusts my modified value/'

For example;

{
  "username": "tanvexar",
  "role": "user"
}

{
  "username": "tanvexar",
  "role": "user"
}

Normal User ↓ role = user ↓ JWT ↓ Server ↓ Normal Access

If the application incorrectly trusts a modified claim:

{
  "username": "tanvexar",
  "role": "admin"
}

{
  "username": "tanvexar",
  "role": "admin"
}

Attacker ↓ role = admin ↓ Modified JWT ↓ Server incorrectly trusts it ↓ Admin Access

The real impact depends on what the server trusts and what that trust allows the attacker to do.

✅ "Can I make the server accept my changed JWT and trust the changed values?"