Token generation and validation in NestJS - Step-by-Step Execution

Concept Flow - Token generation and validation

Start Request

↓

Generate Token

↓

Send Token to Client

↓

Client Sends Token Back

↓

Validate Token

↓

Allow Access

↓

End

This flow shows how a token is created, sent to the client, then validated on future requests to allow or deny access.

Execution Sample

NestJS

const token = this.jwtService.sign(payload);
// send token
const decoded = this.jwtService.verify(token);
if (decoded) {
  // access granted
}

This code generates a token from a payload, then verifies it to check if access should be granted.

Execution Table

Step	Action	Input	Output	Notes
1	Generate token	{ userId: 1 }	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...	Token created from payload
2	Send token	Token string	Token sent to client	Client stores token
3	Client sends token back	Token string	Token received by server	Server prepares to validate
4	Validate token	Token string	{ userId: 1, iat: 1680000000 }	Token decoded successfully
5	Check validity	Decoded payload	Access granted	Token is valid, user allowed
6	Validate token	Invalid token string	Error thrown	Token invalid or expired
7	Check validity	Error	Access denied	User denied access due to invalid token

💡 Execution stops when token is either validated successfully or rejected due to invalidity.

Variable Tracker

Variable	Start	After Step 1	After Step 4	After Step 6
payload	{ userId: 1 }	{ userId: 1 }	{ userId: 1 }	{ userId: 1 }
token	undefined	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...	invalid_token_string
decoded	undefined	undefined	{ userId: 1, iat: 1680000000 }	Error thrown

Key Moments - 3 Insights

Why does the token look like a long random string?

The token is a signed string that encodes the payload securely. See execution_table step 1 where the payload is converted into the token string.

What happens if the token is expired or tampered with?

At step 6 in the execution_table, the validation fails and an error is thrown, leading to access denial at step 7.

Why do we check the decoded payload after verifying the token?

Because verifying the token returns the original payload if valid, which we use to confirm user identity and permissions (step 5).

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at step 4 when validating a valid token?

A Error thrown

B { userId: 1, iat: 1680000000 }

C Access denied

D Token sent to client

💡 Hint

Check the 'Output' column for step 4 in the execution_table.

At which step does the server deny access due to an invalid token?

A Step 3

B Step 5

C Step 7

D Step 1

💡 Hint

Look for 'Access denied' in the 'Output' column of the execution_table.

If the payload changes, how does it affect the token in variable_tracker after step 1?

A Token string changes to reflect new payload

B Token remains the same

C Decoded payload changes but token stays same

D Payload does not affect token

💡 Hint

Refer to variable_tracker showing token value after step 1 depends on payload.

Concept Snapshot

Token generation and validation in NestJS:
- Use jwtService.sign(payload) to create a token.
- Send token to client for future requests.
- Use jwtService.verify(token) to decode and validate.
- If valid, allow access; if invalid, deny access.
- Tokens secure user identity and session info.

Full Transcript

This visual execution shows how NestJS generates and validates tokens. First, a payload like { userId: 1 } is signed into a token string. This token is sent to the client, who stores it. When the client makes requests, it sends the token back. The server verifies the token. If valid, it decodes the payload and grants access. If invalid or expired, it denies access. Variables like payload, token, and decoded data change step-by-step as shown. Key moments include understanding the token format, handling invalid tokens, and why decoding is needed after verification.