Token-based authentication (JWT) in IOT Protocols - Step-by-Step Execution

Process Flow - Token-based authentication (JWT)

Client sends login request

↓

Server verifies credentials

↓

Server creates JWT

↓

Server sends JWT to client

↓

Client stores JWT

↓

Client sends JWT with requests

↓

Server verifies JWT

↓

Allow

This flow shows how a client logs in, receives a JWT token, and uses it for future requests that the server verifies.

Execution Sample

IOT Protocols

POST /login
Server: verify user
Server: create JWT token
Client: store token
Client: send token in header
Server: verify token
Server: allow or deny access

This sequence shows the main steps of JWT token creation and usage for authentication.

Process Table

Step	Action	Input	Output	Server State	Client State
1	Client sends login request	username/password	Request received	Waiting for verification	Sent login request
2	Server verifies credentials	username/password	Credentials valid	Credentials verified	Waiting for token
3	Server creates JWT token	User info	JWT token generated	JWT token ready	Waiting for token
4	Server sends JWT to client	JWT token	Token sent	Token sent	Received JWT token
5	Client stores JWT	JWT token	Token stored	Token sent	Token stored
6	Client sends request with JWT	JWT token in header	Request received	Verifying token	Sent request with token
7	Server verifies JWT	JWT token	Token valid	Token verified	Waiting for response
8	Server allows access	Valid token	Access granted	Request processed	Access granted
9	Client receives response	Access granted	Response received	Idle	Received response
10	Client sends request with expired JWT	Expired JWT token	Request received	Verifying token	Sent request with expired token
11	Server verifies JWT	Expired JWT token	Token invalid	Token rejected	Waiting for response
12	Server rejects access	Invalid token	Access denied	Request denied	Access denied
13	Client receives rejection	Access denied	Response received	Idle	Received rejection

💡 Execution stops after client receives access granted or access denied response.

Status Tracker

Variable	Start	After Step 4	After Step 5	After Step 6	After Step 11	Final
JWT Token	None	Generated	Stored by client	Sent with request	Expired/Invalid	None or expired
Server State	Idle	Token ready	Token sent	Verifying token	Token rejected	Idle
Client State	Idle	Waiting for token	Token stored	Sent request with token	Sent request with expired token	Idle

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 invalid as shown in steps 10-12 in the execution_table where the server verifies and rejects the token.

Does the client send username and password every time after login?

No, after login the client sends only the JWT token with requests as shown in steps 6 and 10, not the username/password.

What happens if the credentials are invalid at login?

The server rejects the login immediately as shown in the concept_flow branch 'No' after credential verification.

Visual Quiz - 3 Questions

Look at the execution_table, what is the server state after step 7?

A Token rejected

B Token verified

C Idle

D Waiting for verification

💡 Hint

Check the 'Server State' column at step 7 in the execution_table.

At which step does the client store the JWT token?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Look for the action 'Client stores JWT' in the execution_table.

If the token expires, what will the server do according to the execution_table?

A Allow access

B Ignore the token

C Reject access

D Request new login

💡 Hint

See steps 11 and 12 where the server verifies and rejects an expired token.

Concept Snapshot

Token-based authentication uses JWT tokens to prove identity.
Client logs in with credentials once.
Server creates and sends JWT token.
Client stores and sends JWT with requests.
Server verifies JWT to allow or deny access.
Expired or invalid tokens cause rejection.

Full Transcript

Token-based authentication with JWT works by the client first sending login credentials to the server. The server checks these credentials and if valid, creates a JWT token. This token is sent back to the client, which stores it. For future requests, the client sends the JWT token instead of credentials. The server verifies the token on each request. If the token is valid, access is granted. If the token is expired or invalid, the server rejects the request. This process avoids sending username and password repeatedly and secures communication by using signed tokens.

Practice

1. What is the main purpose of a JWT (JSON Web Token) in IoT device communication?

easy

A. To store large files securely on the device

B. To encrypt all data sent between devices

C. To prove the device's identity without sending passwords repeatedly

D. To replace the device's IP address

Solution

1. Step 1: Understand JWT role in authentication

   JWT tokens are used to prove identity securely without resending passwords each time.

2. Step 2: Compare options with JWT purpose

   Only To prove the device's identity without sending passwords repeatedly matches this purpose; others describe unrelated functions.

3. Final Answer:

   To prove the device's identity without sending passwords repeatedly -> Option C

4. Quick Check:

   JWT = Identity proof without password [OK]

Hint: JWTs prove identity without passwords [OK]

Common Mistakes:

• Thinking JWT encrypts all data
• Confusing JWT with file storage
• Assuming JWT replaces IP addresses

2. Which of the following is the correct structure of a JWT token?

easy

A. header.payload.signature

B. payload.header.signature

C. signature.payload.header

D. header.signature.payload

Solution

1. Step 1: Recall JWT token parts order

   A JWT consists of three parts separated by dots: header, payload, and signature in that order.

2. Step 2: Match options with correct order

   Only header.payload.signature shows header.payload.signature correctly.

3. Final Answer:

   header.payload.signature -> Option A

4. Quick Check:

   JWT format = header.payload.signature [OK]

Hint: JWT parts order: header, payload, signature [OK]

Common Mistakes:

• Mixing the order of parts
• Placing signature before payload
• Confusing payload and header positions

3. Given this JWT payload JSON: {"sub":"device123","exp":1700000000}, what does the "exp" field represent?

medium

A. The token's signature

B. The device's unique ID

C. The encryption algorithm used

D. The token's expiration time as a Unix timestamp

Solution

1. Step 1: Identify the meaning of 'exp' in JWT payload

   The 'exp' field stands for expiration time, given as a Unix timestamp.

2. Step 2: Match 'exp' meaning with options

   The token's expiration time as a Unix timestamp correctly states it is the token's expiration time; others are unrelated.

3. Final Answer:

   The token's expiration time as a Unix timestamp -> Option D

4. Quick Check:

   exp = expiration time [OK]

Hint: "exp" means token expiration time [OK]

Common Mistakes:

• Confusing 'exp' with device ID
• Thinking 'exp' is encryption info
• Mixing 'exp' with signature data

4. You receive this JWT token string: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJkZXZpY2UxMjMiLCJleHAiOjE3MDAwMDAwMDB9. When verifying, you get an error about the signature. What is the most likely cause?

medium

A. The token is missing the expiration field

B. The token's signature does not match because the secret key used is incorrect

C. The header is not base64 encoded

D. The payload is missing the device ID

Solution

1. Step 1: Understand signature verification in JWT

   Signature errors usually happen when the secret key used to verify does not match the one used to sign.

2. Step 2: Check other options for signature error cause

   Missing payload fields or encoding issues cause different errors, not signature mismatch.

3. Final Answer:

   The token's signature does not match because the secret key used is incorrect -> Option B

4. Quick Check:

   Signature error = wrong secret key [OK]

Hint: Signature errors usually mean wrong secret key [OK]

Common Mistakes:

• Assuming missing fields cause signature errors
• Ignoring base64 encoding correctness
• Thinking expiration absence causes signature failure

5. You want to limit IoT device access by making JWT tokens expire after 10 minutes. Which approach correctly sets this expiration in the token payload?

hard

A. Set the "exp" field to the current Unix timestamp plus 600 seconds

B. Set the "iat" field to 600

C. Set the "exp" field to the current date string

D. Omit the "exp" field to allow unlimited token life

Solution

1. Step 1: Understand JWT expiration setting

   The 'exp' field must be a Unix timestamp indicating when the token expires, so add 600 seconds (10 minutes) to current time.

2. Step 2: Evaluate other options

   'iat' is issued-at time, not expiration; date string is invalid format; omitting 'exp' disables expiration.

3. Final Answer:

   Set the "exp" field to the current Unix timestamp plus 600 seconds -> Option A

4. Quick Check:

   Use 'exp' with timestamp + 600 seconds [OK]

Hint: Use 'exp' = now + 600 seconds for 10-minute expiry [OK]

Common Mistakes:

• Using 'iat' instead of 'exp' for expiration
• Setting 'exp' as a date string
• Leaving out 'exp' to limit token life