Introduction

Imagine you walk into your favorite pizza shop. Instead of the shopkeeper remembering you every time, they give you a pizza card with your details and a stamp. Next time, you just show the card — no need for the shopkeeper to check records again.

That pizza card is like a JWT (JSON Web Token) in the digital world. It’s a secure way to prove who you are and what you can do, without making the server keep track of you.

What is JWT?

A JWT (JSON Web Token) is a compact, digitally signed (using HMAC, RSA, or ECDSA) token used to securely transfer information between two parties (usually client ↔ server).

• It is stateless (server doesn’t need to remember you).

• Commonly used for authentication (who you are) and authorization (what you can do).

Key Terminologies (Explained Simply + Pizza Analogy)

• Sessions (Stateful) → Like a shopkeeper keeping a notebook of all customers. The server stores who you are.

• Tokens (Stateless) → Like a pizza card given to you. You carry it, the shop doesn’t remember.

• Cookies → Like keeping your pizza card in your wallet for later use.

• Authentication → Proving it’s really you (showing ID).

• Authorization → Checking what you’re allowed to order (Regular vs VIP pizza).

• Encryption → Secretly locking the pizza card so no one can copy it.

• Signature → The shop’s official stamp — ensures your card is genuine and not forged.

---

Internal Working of JWT :

A JWT is made of three parts, separated by dots (.):

xxxxx.yyyyy.zzzzz

1. Header

   • Contains metadata: type (JWT) and signing algorithm (e.g., HS256).

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

2. Payload

   • Contains claims (user info + permissions). Example:

    {
      "sub": "1234567890",
      "name": "Alice",
      "role": "admin",
      "exp": 1736243722
    }

• Claims can be:

  • Registered: Standard ones like exp (expiry), sub (subject).

  • Public: Custom claims (e.g., role: admin).

  • Private: Agreed between parties.

3. Signature

   • Ensures integrity.

   • Created as:

    HMACSHA256(
       base64UrlEncode(header) + "." + base64UrlEncode(payload), 
       secret
    )

• If someone tampers with the payload, the signature won’t match → token invalid.

This makes JWT trustworthy and tamper-proof.

---

Why JWT Over Sessions?

Let’s revisit the pizza chain example:

• If every shop uses sessions, each one keeps a notebook of all customers. But when the chain expands across cities, syncing becomes a nightmare.

• With JWT (pizza card):

  • You log in once → get a signed card (token).

  • You can show it in any branch (any server/microservice).

  • The shop just verifies the stamp (signature) — no syncing required.

This is why JWT is preferred in modern apps with microservices, mobile apps, and cloud environments.

---

Where is JWT Used in Real Life?

• Single Sign-On (SSO) → One login works for Gmail, YouTube, Drive.

• APIs & Mobile Apps → Uber, Paytm, Instagram use JWT for authentication.

• Microservices → Each service validates the token independently.

• Cloud Platforms → AWS, GCP, Azure often rely on JWTs for identity and access management.

---

What is a Refresh Token?

1. The Problem with Access Tokens

• JWT access tokens usually have a short lifespan (e.g., 15 minutes).

• If stolen, they cause less damage, but the user would need to log in again when expired → bad user experience.

2. Solution: Refresh Token

• A Refresh Token is a long-lived token issued alongside the access token.

When the access token expires, the client sends the refresh token to get a new access token without logging in again.

Flow Diagram :-

---

What is JWE (JSON Web Encryption) ?

• A JWT that is encrypted, not just signed.

• Used when payload has sensitive data (e.g., PII, financial info).

• Even though JWE can also have expiry and claims, its purpose is confidentiality, not session renewal.

• JWE = adds encryption on top of JWT.

---

Quick Recap

JWT vs JWE vs Refresh Token

• JWT (Access Token): A signed token carrying claims, usually short-lived. Used in each request to prove identity.

• JWE: An encrypted JWT used when confidentiality of claims is critical (e.g., user’s personal or financial details).

• Refresh Token: Issued alongside JWT, but not with JWE. Its purpose is to renew expired JWTs without forcing the user to log in again.

In practice, your system may look like this:

1. Server issues JWT Access Token (short-lived) + Refresh Token (long-lived).

2. JWT is used for API calls.

3. When JWT expires → Refresh Token is sent to get a new one.

4. If the access token must hide sensitive claims → server issues it as a JWE

Thanks for reading! :)
If this helped you understand JWTs better, feel free to share it or bookmark for later. Got questions or feedback? Drop a comment — let’s learn together!