JWT authentication flow in Astro - Performance & Optimization

Performance: JWT authentication flow

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by how tokens are handled and verified during user authentication.

Handling JWT tokens on the client side for user authentication

Astro

const [user, setUser] = useState(null);
useEffect(() => {
  const token = localStorage.getItem('jwt');
  if (token) {
    // decode token asynchronously once on mount
    decodeJWTAsync(token).then(setUser);
  }
}, []);

Decoding JWT asynchronously once on component mount avoids blocking the main thread during renders.

📈 Performance GainReduces blocking to near 0ms on renders, improving interaction responsiveness (INP).

Handling JWT tokens on the client side for user authentication

Astro

const token = localStorage.getItem('jwt');
if (token) {
  // decode and verify token on every render synchronously
  const user = decodeJWT(token);
  renderUser(user);
}

Decoding and verifying the JWT token synchronously on every render blocks the main thread and delays UI updates.

📉 Performance CostBlocks rendering for 50-100ms on each render, causing input lag and slower interaction responsiveness.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Synchronous JWT decode on every render	Minimal	0	High due to blocking JS	[X] Bad
Asynchronous JWT decode once on mount	Minimal	0	Low, non-blocking	[OK] Good
Reading token from localStorage on every request	Minimal	0	Low but repeated sync access	[!] OK
Caching token in memory for requests	Minimal	0	Lowest, no repeated sync access	[OK] Good

Rendering Pipeline

JWT token decoding and verification happens in JavaScript execution before rendering user-specific content. Inefficient handling blocks the main thread delaying style calculation and paint.

→JavaScript Execution

→Style Calculation

→Layout

→Paint

⚠️ BottleneckJavaScript Execution blocking main thread

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by how tokens are handled and verified during user authentication.

Optimization Tips

1Decode JWT tokens asynchronously to avoid blocking the main thread.

2Cache JWT tokens in memory to reduce repeated synchronous localStorage access.

3Avoid decoding tokens on every render; do it once on component mount or login.

Performance Quiz - 3 Questions

What is the main performance problem with decoding JWT tokens synchronously on every render?

A It increases network payload size.

B It blocks the main thread causing slower interaction responsiveness.

C It causes layout shifts on the page.

D It reduces the security of the token.

DevTools: Performance

How to check: Record a performance profile while loading the page and interacting. Look for long tasks blocking the main thread during authentication steps.

What to look for: Look for long JavaScript execution times related to token decoding and synchronous localStorage access causing input delays.

Practice

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

easy

A. To securely transmit user identity and permissions between client and server

B. To store user passwords on the client side

C. To encrypt all user data in the database

D. To replace cookies for storing session data only

Solution

1. Step 1: Understand JWT role in authentication

   JWTs carry encoded user identity and permissions safely between client and server.

2. Step 2: Compare options with JWT purpose

   Only To securely transmit user identity and permissions between client and server correctly describes JWT's role; others confuse JWT with password storage or encryption.

3. Final Answer:

   To securely transmit user identity and permissions between client and server -> Option A

4. Quick Check:

   JWT purpose = secure token for identity [OK]

Hint: JWTs carry user info safely between client and server [OK]

Common Mistakes:

• Thinking JWT stores passwords
• Confusing JWT with database encryption
• Assuming JWT replaces cookies entirely

2. Which of the following is the correct way to send a JWT token in an HTTP request header?

easy

A. Authorization: Bearer <token>

B. Token: JWT <token>

C. Auth-Token: <token>

D. JWT-Authorization: Bearer <token>

Solution

1. Step 1: Recall standard JWT header format

   The standard way to send JWT is in the Authorization header with 'Bearer' prefix.

2. Step 2: Match options to standard

   Only Authorization: Bearer <token> matches the correct syntax: 'Authorization: Bearer <token>'. Others use incorrect header names or formats.

3. Final Answer:

   Authorization: Bearer <token> -> Option A

4. Quick Check:

   JWT header = Authorization: Bearer token [OK]

Hint: JWTs go in 'Authorization: Bearer <token>' header [OK]

Common Mistakes:

• Using wrong header names like 'Token' or 'Auth-Token'
• Omitting 'Bearer' prefix
• Adding extra words like 'JWT' before token

3. Given this Astro server code snippet handling JWT verification, what will be the output if the token is invalid?

import jwt from 'jsonwebtoken';

export async function get({ request }) {
  const authHeader = request.headers.get('Authorization');
  if (!authHeader) return new Response('No token', { status: 401 });

  const token = authHeader.split(' ')[1];
  try {
    const user = jwt.verify(token, 'secretkey');
    return new Response(`User: ${user.name}`, { status: 200 });
  } catch {
    return new Response('Invalid token', { status: 403 });
  }
}

medium

A. Response with status 200 and user name

B. Response with status 401 and message 'No token'

C. Response with status 403 and message 'Invalid token'

D. Response with status 500 and server error message

Solution

1. Step 1: Analyze token verification flow

   If token is invalid, jwt.verify throws an error caught by catch block.

2. Step 2: Check catch block response

   The catch block returns status 403 with message 'Invalid token'.

3. Final Answer:

   Response with status 403 and message 'Invalid token' -> Option C

4. Quick Check:

   Invalid token triggers 403 response [OK]

Hint: Invalid JWT triggers catch block with 403 response [OK]

Common Mistakes:

• Assuming invalid token returns 401
• Confusing catch block with success path
• Expecting server error instead of 403

4. Identify the bug in this Astro JWT authentication snippet:

export async function get({ request }) {
  const authHeader = request.headers.get('Authorization');
  if (!authHeader) return new Response('No token', { status: 401 });

  const token = authHeader.split(' ')[0];
  try {
    const user = jwt.verify(token, 'secretkey');
    return new Response(`User: ${user.name}`, { status: 200 });
  } catch {
    return new Response('Invalid token', { status: 403 });
  }
}

medium

A. Missing secret key in jwt.verify call

B. Token extraction uses wrong index from split

C. No check for missing Authorization header

D. Response status codes are reversed

Solution

1. Step 1: Check how token is extracted

   Token is extracted using authHeader.split(' ')[0], which gets 'Bearer' instead of the token.

2. Step 2: Identify correct token index

   The token is at index 1 after splitting by space, so index 0 is wrong.

3. Final Answer:

   Token extraction uses wrong index from split -> Option B

4. Quick Check:

   Token index must be 1, not 0 [OK]

Hint: Token is after 'Bearer', so use split index 1 [OK]

Common Mistakes:

• Using split index 0 instead of 1
• Forgetting to check Authorization header
• Mixing up status codes 401 and 403

5. You want to implement a refresh token flow in Astro using JWT. Which approach correctly handles token expiration and refresh securely?

hard

A. Send access token only once at login and never refresh it; rely on long expiration time

B. Store both access and refresh tokens in localStorage and refresh access token automatically on every request

C. Store refresh token in localStorage and access token in URL query parameters for easy access

D. Store access token in memory and refresh token in HttpOnly cookie; use refresh token to get new access token when expired

Solution

1. Step 1: Understand secure token storage

   Access tokens should be stored in memory to reduce exposure; refresh tokens in HttpOnly cookies to prevent JavaScript access.

2. Step 2: Use refresh token to get new access token

   When access token expires, client uses refresh token securely to request a new access token.

3. Final Answer:

   Store access token in memory and refresh token in HttpOnly cookie; use refresh token to get new access token when expired -> Option D

4. Quick Check:

   Secure refresh flow = memory + HttpOnly cookie [OK]

Hint: Keep refresh token HttpOnly, access token in memory [OK]

Common Mistakes:

• Storing tokens in localStorage (XSS risk)
• Never refreshing tokens (causes logout)
• Putting tokens in URL (exposes tokens)