JWT structure and flow in Rest API

Introduction

JWT helps safely share information between two parties. It makes sure the data is real and not changed.

When a website needs to remember who you are after you log in.

When a mobile app talks to a server and needs to prove your identity.

When different parts of a system need to share user info securely.

When you want to avoid sending your password every time you ask for data.

Syntax

Rest API

header.payload.signature

The JWT has three parts separated by dots.

Each part is base64 encoded text.

Examples

This is a full JWT example with header, payload, and signature.

Rest API

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NSIsIm5hbWUiOiJKb2huIERvZSJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Shows the JSON content inside each part before encoding.

Rest API

{
  "alg": "HS256",
  "typ": "JWT"
}.
{
  "userId": "12345",
  "name": "John Doe"
}.
Signature

Sample Program

This program creates a JWT token with user info, then decodes it back to show the data.

Rest API

import jwt

# Secret key to sign the token
secret = 'mysecretkey'

# Data to include in the token
payload = {'userId': '12345', 'name': 'John Doe'}

# Create a JWT token
encoded_jwt = jwt.encode(payload, secret, algorithm='HS256')
print('JWT Token:', encoded_jwt)

# Decode the JWT token
decoded_payload = jwt.decode(encoded_jwt, secret, algorithms=['HS256'])
print('Decoded Payload:', decoded_payload)

Important Notes

The header tells what algorithm is used to sign the token.

The payload holds the data you want to share.

The signature proves the token is not changed and is from a trusted source.

Summary

JWT has three parts: header, payload, and signature.

It is used to safely share data between systems.

Tokens are signed to prevent tampering.

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