JWT structure and flow in Rest API - Step-by-Step Execution

Concept Flow - JWT structure and flow

Client sends login request

↓

Server verifies credentials

↓

Server creates JWT

↓

Server sends JWT to client

↓

Client stores JWT

↓

Client sends JWT with API requests

↓

Server verifies JWT

↓

Allow access

This flow shows how a client logs in, receives a JWT, stores it, and uses it for authenticated requests, while the server verifies the token each time.

Execution Sample

Rest API

header = {"alg": "HS256", "typ": "JWT"}
payload = {"user_id": 123, "exp": 1680000000}
token = encode(header, payload, secret)
// Client sends token with requests
// Server decodes and verifies token

This code creates a JWT token with header and payload, then encodes it with a secret key.

Execution Table

Step	Action	Data Involved	Result/Output
1	Client sends login request	Username, Password	Request received by server
2	Server verifies credentials	Username, Password	Credentials valid? Yes
3	Server creates JWT	Header, Payload, Secret	JWT token generated
4	Server sends JWT to client	JWT token	Client receives token
5	Client stores JWT	JWT token	Token saved locally
6	Client sends JWT with API request	JWT token in Authorization header	Request sent to server
7	Server verifies JWT	JWT token, Secret	Token valid? Yes
8	Server allows access	Valid token	Requested data sent
9	Client sends JWT with API request	JWT token in Authorization header	Request sent to server
10	Server verifies JWT	JWT token, Secret	Token valid? No (expired or tampered)
11	Server rejects request	Invalid token	Access denied response sent

💡 Execution stops when server rejects invalid or expired JWT token.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	After Step 10
header	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}	{"alg": "HS256", "typ": "JWT"}
payload	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}	{"user_id": 123, "exp": 1680000000}
token	null	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTY4MDAwMDAwMH0.signature

Key Moments - 3 Insights

Why does the server reject a request even if the client sends a token?

Because the token might be expired or tampered with, as shown in execution_table step 10 where the server finds the token invalid and rejects the request in step 11.

What is inside the JWT token that allows the server to verify it?

The JWT contains a header and payload signed with a secret. The server uses the secret to verify the signature, as shown in step 3 and step 7 of the execution_table.

Does the client need to send username and password with every request?

No, after login the client sends only the JWT token with requests, as shown in steps 6 and 9, so the server can verify the token without needing credentials again.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the server create the JWT token?

A Step 3

B Step 5

C Step 2

D Step 7

💡 Hint

Check the 'Action' column in execution_table for the step where 'Server creates JWT' happens.

According to variable_tracker, what is the value of 'token' after Step 5?

A null

B Header and payload only

C Encoded JWT string

D Secret key

💡 Hint

Look at the 'token' row under 'After Step 5' column in variable_tracker.

At which step does the server reject the request due to an invalid token?

A Step 8

B Step 11

C Step 10

D Step 9

💡 Hint

Check execution_table for the step where 'Server rejects request' is the result.

Concept Snapshot

JWT Structure and Flow:
- Client logs in with credentials
- Server verifies and creates JWT (header.payload.signature)
- Client stores and sends JWT with requests
- Server verifies JWT signature and expiry
- Valid token grants access; invalid token denies
- JWT allows stateless, secure API authentication

Full Transcript

This visual execution shows how JWT works in a REST API. First, the client sends login info. The server checks it. If correct, the server creates a JWT token with header and payload signed by a secret. The server sends this token to the client. The client saves it and sends it with future requests. The server checks the token each time. If the token is valid, the server allows access. If the token is invalid or expired, the server rejects the request. Variables like header, payload, and token change as the process goes. Key moments include understanding why tokens can be rejected, what is inside a JWT, and that credentials are not sent every time. The quizzes test your understanding of these steps and variable states.

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