Session-based vs token-based auth in Node.js - Visual Side-by-Side Comparison

Concept Flow - Session-based vs token-based auth

User sends login request

↓

Server verifies credentials

↓

Session-based Auth

↓

Create session on server

↓

Send session ID cookie

↓

Client stores cookie

↓

Server checks session ID

↓

Allow or deny access

↓

Logout

↓

Destroy session on server

This flow shows how a user logs in, and the server either creates a session stored on server or a token sent to client, then how each request is authenticated differently.

Execution Sample

Node.js

app.post('/login', (req, res) => {
  // Verify user
  // Session: req.session.user = userId
  // Token: const token = jwt.sign({id: userId}, secret)
  // Send session cookie or token
})

This code snippet shows a login route where server verifies user and either creates a session or generates a token.

Execution Table

Step	Action	Session-based Auth	Token-based Auth	Result
1	User sends login request	No session yet	No token yet	Server receives credentials
2	Server verifies credentials	Credentials valid?	Credentials valid?	Yes, proceed
3	Create auth data	Create session on server with user ID	Create JWT token with user ID payload	Auth data ready
4	Send auth data to client	Send session ID cookie	Send token in response body	Client receives auth data
5	Client stores auth data	Browser stores cookie automatically	Client stores token in memory or localStorage	Auth data stored
6	Client makes authenticated request	Browser sends cookie automatically	Client sends token in Authorization header	Request sent with auth
7	Server verifies auth	Check session ID in server store	Verify token signature and expiry	Auth verified or rejected
8	Access granted or denied	Allow or deny based on session	Allow or deny based on token	Response sent
9	User logs out	Client requests logout	Client deletes token locally	Session destroyed or token discarded
10	Server cleans up	Destroy session on server	No server cleanup needed	Logout complete
11	Next request	No session cookie, access denied	No token sent, access denied	User must login again
12	End	Session expired or destroyed	Token expired or deleted	Authentication ends

💡 Authentication ends when session is destroyed or token expires/deleted, user must login again.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 6	After Step 9	Final
sessionStore	{}	{ userId: 'abc123' }	{ userId: 'abc123' }	{ userId: 'abc123' }	{}	{}
sessionCookie	none	none	set in response	sent with request	deleted	none
token	none	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...	sent in response	sent in Authorization header	deleted from client	none

Key Moments - 3 Insights

Why does session-based auth require server storage but token-based does not?

Session-based auth stores session data on the server (see sessionStore variable in execution_table step 3), so server must keep track. Token-based auth encodes user info in the token itself, so server just verifies token signature without storing session.

How does the client send authentication data differently in session vs token auth?

In session auth, the browser automatically sends the session cookie with each request (see sessionCookie in variable_tracker after step 6). In token auth, client code must add the token manually to the Authorization header.

What happens on logout in both methods?

In session auth, server destroys the session (sessionStore cleared at step 9). In token auth, client deletes the token locally; server usually does not track tokens.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What is created in token-based auth?

A A JWT token with user ID payload

B A cookie with session ID

C A session stored on the server

D A logout request

💡 Hint

Check the 'Token-based Auth' column at step 3 in execution_table

According to variable_tracker, what happens to sessionStore after logout?

A It remains unchanged

B It is cleared (empty object)

C It stores the token

D It stores the session cookie

💡 Hint

Look at sessionStore values after step 9 in variable_tracker

In session-based auth, how does the client send authentication data on requests?

A Includes token in request body

B Manually adds token to Authorization header

C Sends session cookie automatically

D Sends user ID in URL

💡 Hint

Refer to execution_table step 6 and variable_tracker sessionCookie after step 6

Concept Snapshot

Session-based Auth:
- Server stores session data
- Client gets session ID cookie
- Browser sends cookie automatically
- Server checks session on each request

Token-based Auth:
- Server creates signed token (JWT)
- Client stores token (localStorage or memory)
- Client sends token in Authorization header
- Server verifies token signature

Logout:
- Session destroyed on server
- Token deleted on client

Tokens are stateless; sessions require server memory.

Full Transcript

This visual execution compares session-based and token-based authentication in Node.js. When a user logs in, the server verifies credentials. For session-based auth, the server creates a session stored in memory or database and sends a session ID cookie to the client. The browser stores this cookie and sends it automatically with each request. The server checks the session ID to authenticate. For token-based auth, the server creates a signed JWT token containing user info and sends it to the client. The client stores the token and sends it manually in the Authorization header on requests. The server verifies the token signature and expiry to authenticate. On logout, session-based auth destroys the session on the server, while token-based auth requires the client to delete the token. This means session-based auth needs server storage and management, while token-based auth is stateless and easier to scale. The execution table and variable tracker show each step and how data changes. Key moments clarify common confusions about storage, client sending methods, and logout behavior.

Practice

1. Which of the following best describes session-based authentication in Node.js?

easy

A. User data is stored on the server and linked to the client via cookies.

B. User credentials are sent with every request without storing data on the server.

C. A signed token is stored on the server and sent to the client.

D. Authentication is done only once without any session or token.

Solution

1. Step 1: Understand session-based auth storage

   Session-based authentication stores user info on the server side, typically in memory or a database.

2. Step 2: Identify how client links to session

   The client receives a cookie that holds a session ID to link requests to the stored session data.

3. Final Answer:

   User data is stored on the server and linked to the client via cookies. -> Option A

4. Quick Check:

   Session-based auth = server stores data + cookie link [OK]

Hint: Session auth stores data server-side, linked by cookies [OK]

Common Mistakes:

• Thinking tokens are stored on the server in session auth
• Confusing session ID with user credentials
• Assuming session data is stored on the client

2. Which code snippet correctly sets a cookie for session-based authentication in Express.js?

easy

A. res.session('abc123');

B. res.setHeader('Authorization', 'Bearer abc123');

C. res.sendToken('abc123');

D. res.cookie('sessionId', 'abc123', { httpOnly: true });

Solution

1. Step 1: Identify Express.js method to set cookies

   Express uses res.cookie() to set cookies on the client with options like httpOnly for security.

2. Step 2: Match correct syntax for session cookie

   res.cookie('sessionId', 'abc123', { httpOnly: true }) correctly sets a cookie named 'sessionId'.

3. Final Answer:

   res.cookie('sessionId', 'abc123', { httpOnly: true }); -> Option D

4. Quick Check:

   Use res.cookie() to set session cookies [OK]

Hint: Use res.cookie() to set cookies in Express [OK]

Common Mistakes:

• Using res.setHeader for cookies instead of Authorization header
• Assuming res.sendToken is a valid Express method
• Trying to set session with res.session which doesn't exist

3. Given this token-based auth code snippet, what will be the output if the token is valid?

const jwt = require('jsonwebtoken');
const token = req.headers.authorization?.split(' ')[1];
try {
  const user = jwt.verify(token, 'secretKey');
  res.send(`User ID: ${user.id}`);
} catch {
  res.status(401).send('Unauthorized');
}

medium

A. SyntaxError

B. Unauthorized

C. User ID: [user's id from token]

D. Token string printed as is

Solution

1. Step 1: Extract token from Authorization header

   The code splits the 'Authorization' header to get the token part after 'Bearer'.

2. Step 2: Verify token and extract user info

   jwt.verify checks the token with 'secretKey' and returns the decoded user object if valid.

3. Final Answer:

   User ID: [user's id from token] -> Option C

4. Quick Check:

   Valid token returns decoded user info [OK]

Hint: Valid JWT returns decoded user info, else error [OK]

Common Mistakes:

• Assuming token is printed directly without decoding
• Confusing token verification failure with syntax error
• Ignoring optional chaining and possible undefined token

4. Identify the bug in this session-based auth middleware code snippet:

function auth(req, res, next) {
  if (!req.session.user) {
    res.status(401).send('Not logged in');
  }
  next();
}

medium

A. req.session.user should be req.user instead.

B. Missing return after sending 401 response causes next() to run anyway.

C. next() should be called before checking session.

D. res.status should be res.sendStatus.

Solution

1. Step 1: Analyze control flow after sending response

   After res.status(401).send(), the function continues and calls next(), allowing unauthorized access.

2. Step 2: Fix by adding return to stop execution

   Adding return before res.status stops the function, preventing next() from running when unauthorized.

3. Final Answer:

   Missing return after sending 401 response causes next() to run anyway. -> Option B

4. Quick Check:

   Return after response to stop middleware [OK]

Hint: Add return after res.send to prevent next() running [OK]

Common Mistakes:

• Calling next() before checking session
• Confusing req.session.user with req.user
• Using res.sendStatus instead of res.status().send()

5. You want to build a Node.js app that supports multiple devices per user and scales easily. Which authentication method is best and why?

hard

A. Token-based auth, because tokens are stateless and work well across devices.

B. Token-based auth, because it requires server to store session data.

C. Session-based auth, because cookies automatically sync across devices.

D. Session-based auth, because it stores user data on the server for security.

Solution

1. Step 1: Consider multi-device and scalability needs

   Supporting multiple devices means the server should not rely on storing session state for each device.

2. Step 2: Choose token-based auth for statelessness

   Token-based auth uses signed tokens stored client-side, allowing stateless servers and easy scaling.

3. Final Answer:

   Token-based auth, because tokens are stateless and work well across devices. -> Option A

4. Quick Check:

   Stateless tokens = scalable multi-device auth [OK]

Hint: Use token auth for scalable, multi-device apps [OK]

Common Mistakes:

• Thinking sessions sync automatically across devices
• Believing token auth requires server session storage
• Choosing session auth for scalability