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.