Why JWT structure and flow in Rest API? - Purpose & Use Cases

The Big Idea

What if you could prove who you are online with a tiny, secure token instead of typing your password everywhere?

The Scenario

Imagine you have a website where users log in, and you want to remember who they are as they move from page to page. Without a good system, you might try to check their username and password every single time they click a link.

The Problem

This manual way is slow and frustrating because it means asking users to log in repeatedly or storing sensitive info everywhere. It's easy to make mistakes that let strangers pretend to be someone else, causing security problems.

The Solution

JWT (JSON Web Token) solves this by creating a small, secure package of information that proves who the user is. This token travels with the user's requests, so the server can quickly check it without asking for passwords again and again.

Before vs After

✗ Before

if user_logged_in:
    check_password_every_request()
else:
    ask_login()

✓ After

token = create_jwt(user_info)
if verify_jwt(token):
    allow_access()

What It Enables

JWT makes it easy and safe to keep users logged in across many pages and services without slowing things down or risking security.

Real Life Example

When you log into an online store, JWT lets the site remember you as you browse products, add items to your cart, and check out—all without asking you to log in again.

Key Takeaways

Manual login checks slow down apps and risk security.

JWT packages user info securely for easy verification.

This keeps users logged in smoothly and safely.

Practice

1. What are the three main parts of a JWT (JSON Web Token)?

easy

A. Header, Payload, Signature

B. Username, Password, Token

C. Request, Response, Token

D. Key, Value, Token

Solution

1. Step 1: Understand JWT structure basics

   A JWT is made of three parts separated by dots.

2. Step 2: Identify the parts

   The three parts are Header (metadata), Payload (claims), and Signature (verification).

3. Final Answer:

   Header, Payload, Signature -> Option A

4. Quick Check:

   JWT parts = Header, Payload, Signature [OK]

Hint: Remember JWT has 3 parts separated by dots [OK]

Common Mistakes:

• Confusing JWT parts with user credentials
• Thinking JWT has only two parts
• Mixing up token with request/response

2. Which of the following is the correct format of a JWT string?

easy

A. header|payload|signature

B. header-payload-signature

C. header.payload.signature

D. header_payload_signature

Solution

1. Step 1: Recall JWT encoding format

   JWT parts are base64url encoded and joined by dots.

2. Step 2: Identify correct separator

   The correct separator between parts is a dot ('.').

3. Final Answer:

   header.payload.signature -> Option C

4. Quick Check:

   JWT format uses dots '.' [OK]

Hint: JWT parts are joined by dots '.' [OK]

Common Mistakes:

• Using dashes or underscores instead of dots
• Confusing with other token formats
• Not encoding parts properly

3. Given this JWT payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}, what does the iat field represent?

medium

A. Issuer of the token

B. Issued at time

C. Expiration time

D. Subject identifier

Solution

1. Step 1: Understand JWT standard claims

   Common claims include 'sub' (subject), 'iat' (issued at), 'exp' (expiration), and 'iss' (issuer).

2. Step 2: Identify meaning of 'iat'

   'iat' stands for 'issued at' and marks the time the token was created.

3. Final Answer:

   Issued at time -> Option B

4. Quick Check:

   'iat' = issued at time [OK]

Hint: 'iat' means when token was issued [OK]

Common Mistakes:

• Confusing 'iat' with expiration time
• Mixing 'sub' and 'iss' claims
• Assuming 'iat' is issuer

4. You receive a JWT but the signature verification fails. What is the most likely cause?

medium

A. The secret key used to sign the token is different

B. The token payload is empty

C. The header is missing

D. The token is not base64 encoded

Solution

1. Step 1: Understand signature verification

   The signature is created using a secret key and the header and payload.

2. Step 2: Identify cause of verification failure

   If the secret key used to verify differs from the signing key, verification fails.

3. Final Answer:

   The secret key used to sign the token is different -> Option A

4. Quick Check:

   Signature fails if secret keys differ [OK]

Hint: Signature fails if secret keys don't match [OK]

Common Mistakes:

• Assuming empty payload causes signature failure
• Thinking missing header always breaks signature
• Confusing encoding with signature verification

5. In a REST API, after a user logs in, the server issues a JWT. Which step correctly describes the flow for authenticating future requests using this JWT?

hard

A. Client sends JWT in URL query; server ignores signature and trusts token

B. Client sends username and password with every request; server creates new JWT each time

C. Server stores JWT in database and checks it on each request

D. Client sends JWT in Authorization header; server verifies signature and extracts user info

Solution

1. Step 1: Understand JWT usage in REST API

   After login, server issues JWT to client to prove identity without resending credentials.

2. Step 2: Identify correct authentication flow

   Client sends JWT in Authorization header; server verifies signature and extracts user info to authenticate.

3. Final Answer:

   Client sends JWT in Authorization header; server verifies signature and extracts user info -> Option D

4. Quick Check:

   JWT sent in header and verified by server [OK]

Hint: JWT goes in Authorization header, server verifies signature [OK]

Common Mistakes:

• Sending credentials every request instead of JWT
• Storing JWT server-side defeats statelessness
• Ignoring signature verification risks security