DEV Community: Khaled Saeed

Access and Refresh Tokens in Token-Based Authentication

Khaled Saeed — Sat, 02 Aug 2025 22:09:39 +0000

🔑 Token-based authentication has become the standard for modern web applications and APIs. If you've ever wondered why we need both access tokens and refresh tokens, or how they work together to create secure, scalable authentication systems, this article will break it down for you.

🚀 Introduction

🔐 What is Token-Based Authentication?

Token-based authentication is a stateless approach to user authentication where the server generates a cryptographically signed token after successful login. This token contains encoded user information and is sent with every subsequent request to prove the user's identity.

⚖️ Traditional Session vs. Token-Based Authentication

Traditional session-based authentication relies on server-side storage:

👤 User logs in → 🖥️ Server creates a session → 🍪 Session ID stored in cookie
📨 Each request includes the session ID → 🔍 Server looks up session data
💾 Requires server memory/database to maintain session state

Token-based authentication, however, is stateless:

👤 User logs in → 🖥️ Server generates a signed token → 📱 Token sent to client
📨 Each request includes the token → ✅ Server verifies token signature
🚫 No server-side storage needed for authentication state

⚡ The Power of Stateless Authentication

Stateless authentication offers several advantages:

🔄 Scalability: No need to sync session data across multiple servers
🔧 Microservices-friendly: Tokens can be verified independently by any service
📱 Mobile-friendly: Perfect for mobile apps and single-page applications
🔗 Decoupled architecture: Frontend and backend can be completely separate

🎭 Access Tokens vs. Refresh Tokens

Understanding the distinction between these two types of tokens is crucial for implementing secure authentication.

🎫 Access Tokens

Access tokens are short-lived credentials that grant access to protected resources. Think of them as temporary passes that prove you're authorized to perform specific actions.

Key characteristics:

⏰ Lifetime: Typically 15 minutes to 1 hour
💾 Storage: Can be stored in memory, localStorage, or sessionStorage
⚠️ Security risk: Lower (due to short lifespan)
🔄 Usage: Sent with every API request in the Authorization header

🗝️ Refresh Tokens

Refresh tokens are long-lived credentials used exclusively to obtain new access tokens. They're like master keys that can generate new temporary passes.

Key characteristics:

⏳ Lifetime: Days, weeks, or months
🔒 Storage: Should be stored securely (preferably HttpOnly cookies)
🚨 Security risk: Higher (due to long lifespan)
🎯 Usage: Only sent to the authentication endpoint to get new access tokens

Token Flow Diagram

🤔 Why Do We Use Both?

The dual-token approach elegantly solves the security vs. usability dilemma that plagues authentication systems.

🚫 The Problem with Single Token Approaches

Long-lived access tokens create security risks:

💥 If compromised, attackers have extended access
🔒 Difficult to revoke without complex blacklisting
📊 Higher chance of tokens being exposed in logs, URLs, or client-side storage

Short-lived tokens alone hurt user experience:

🔄 Frequent re-authentication required
😤 Poor user experience with constant login prompts
📈 Increased load on authentication servers

⚖️ The Dual-Token Solution

By using both token types, we achieve:

🛡️ Security Benefits:

⏱️ Limited exposure window (short-lived access tokens)
🚫 Ability to quickly revoke access (by invalidating refresh tokens)
🛡️ Reduced risk if access tokens are compromised

😊 Usability Benefits:

✨ Seamless user experience (automatic token refresh)
🚫 No frequent login prompts
📱 Offline capability (cached refresh tokens)

⚡ Performance Benefits:

📉 Reduced authentication server load
🚀 Faster API responses (no session lookups)
💾 Better caching strategies

⚠️ Why Storing Long-lived Access Tokens is Dangerous

Long-lived access tokens in client storage create multiple attack vectors:

🕷️ XSS attacks can steal tokens from localStorage
🦠 Malware can access stored tokens
🕵️ Network interception gives attackers long-term access
📋 Token leakage through logs or error messages

Refresh tokens help by:

🎯 Limiting the blast radius of compromised access tokens
🎛️ Providing centralized revocation control
🔍 Enabling detection of suspicious refresh patterns

🔄 Security Risk Timeline

🔐 Security Tips for Using Refresh Tokens

Implementing refresh tokens securely requires careful consideration of storage, rotation, and monitoring strategies.

🏗️ Token Security Architecture

1. 🏦 Secure Storage Strategies

🖥️ Server-side storage (Recommended):

// Store refresh token in HttpOnly, Secure cookie
app.post('/login', (req, res) => {
  const { accessToken, refreshToken } = generateTokens(user);

  res.cookie('refreshToken', refreshToken, {
    httpOnly: true,     // Prevents XSS access
    secure: true,       // HTTPS only
    sameSite: 'strict', // CSRF protection
    maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
  });

  res.json({ accessToken });
});

✅ Why HttpOnly cookies are preferred:

🛡️ Immune to XSS attacks
🔄 Automatically sent with requests
🔧 Can be configured with security flags

2. 🔄 Implement Token Rotation

Always issue new refresh tokens when they're used:

app.post('/refresh', (req, res) => {
  const { refreshToken } = req.cookies;

  if (!isValidRefreshToken(refreshToken)) {
    return res.status(401).json({ error: 'Invalid refresh token' });
  }

  // Invalidate old refresh token
  revokeRefreshToken(refreshToken);

  // Generate new tokens
  const { accessToken, refreshToken: newRefreshToken } = generateTokens(user);

  // Store new refresh token
  res.cookie('refreshToken', newRefreshToken, cookieOptions);
  res.json({ accessToken });
});

3. ⏰ Set Proper Expiration and Revocation

📊 Implement sliding expiration:

⏳ Refresh tokens expire after inactivity
👥 Active users get extended sessions
🗑️ Inactive tokens automatically expire

🚪 Provide revocation endpoints:

app.post('/logout', (req, res) => {
  const { refreshToken } = req.cookies;

  // Revoke the refresh token
  revokeRefreshToken(refreshToken);

  // Clear the cookie
  res.clearCookie('refreshToken');
  res.json({ message: 'Logged out successfully' });
});

// Revoke all user sessions
app.post('/logout-all', (req, res) => {
  revokeAllUserRefreshTokens(userId);
  res.json({ message: 'Logged out from all devices' });
});

4. 🕵️ Monitor for Suspicious Activity

Implement detection for unusual patterns:

const detectAnomalies = (userId, metadata) => {
  const { ipAddress, userAgent, location } = metadata;

  // Check for suspicious patterns
  const recentActivity = getUserRecentActivity(userId);

  if (isDifferentLocation(recentActivity.location, location) ||
      isDifferentDevice(recentActivity.userAgent, userAgent)) {

    // Trigger security measures
    sendSecurityAlert(userId);
    requireReAuthentication(userId);
  }
};

5. 🔑 Protect Your Token Secrets

🛡️ Key management best practices:

💪 Use strong, randomly generated signing keys
🔄 Rotate keys regularly
🏦 Store keys in secure key management systems (AWS KMS, HashiCorp Vault)
🚫 Never commit keys to version control
🔧 Use different keys for different environments

// Use environment-specific keys
const JWT_SECRET = process.env.JWT_SECRET;
const REFRESH_SECRET = process.env.REFRESH_SECRET;

// Implement key rotation
const getCurrentSigningKey = () => {
  const keyVersion = process.env.KEY_VERSION || 'v1';
  return process.env[`JWT_SECRET_${keyVersion}`];
};

🚀 Advanced Notes

🔐 OAuth 2.0 Best Practices

When implementing OAuth 2.0, follow these guidelines:

🖥️ Use the Authorization Code flow for server-side applications
📱 Implement PKCE (Proof Key for Code Exchange) for public clients
✅ Validate redirect URIs strictly
🛡️ Use state parameters to prevent CSRF attacks

🎯 JWT vs. Opaque Tokens

🎫 JWT (JSON Web Tokens):

📦 Self-contained and stateless
⚡ Can be verified without database lookup
📏 Larger payload size
⏰ Difficult to revoke immediately

🔒 Opaque Tokens:

🎲 Random string references
🔍 Require database lookup for validation
📦 Smaller payload size
🚫 Easy to revoke immediately

Choose based on your specific requirements for scalability vs. control.

📱 PKCE and Single Page Applications

For SPAs and mobile apps, implement PKCE to enhance security:

// Generate code verifier and challenge
const codeVerifier = generateRandomString(43);
const codeChallenge = base64URLEncode(sha256(codeVerifier));

// Authorization request
const authUrl = `${authEndpoint}?` +
  `client_id=${clientId}&` +
  `redirect_uri=${redirectUri}&` +
  `response_type=code&` +
  `code_challenge=${codeChallenge}&` +
  `code_challenge_method=S256`;

🌐 OAuth 2.0 Flow with PKCE

🔄 JWT vs Opaque Token Decision Tree

📚 Further Reading

To deepen your understanding, explore these resources:

📖 OAuth 2.0 RFC 6749 - The official OAuth 2.0 specification
🛡️ OAuth 2.0 Security Best Practices - Latest security recommendations
🔐 Auth0 Documentation - Comprehensive authentication guides
🎫 JWT.io - JWT debugger and library information
🔒 OWASP Authentication Cheat Sheet - Security-focused authentication guidance

🎯 Conclusion

Understanding access and refresh tokens is fundamental to building secure, scalable authentication systems. The key takeaways are:

🎫 Access tokens should be short-lived and used for API requests
🗝️ Refresh tokens should be long-lived, securely stored, and used only for obtaining new access tokens
⚖️ The dual-token approach balances security, usability, and performance
🔧 Proper implementation requires secure storage, token rotation, monitoring, and key management
📈 Always follow current security best practices and consider your specific use case requirements

Remember that security is not a one-time implementation but an ongoing process. Stay updated with the latest security recommendations, monitor your authentication systems, and always prioritize user data protection.

💬 What's your experience with token-based authentication? Have you encountered specific challenges or implemented interesting solutions? Share your thoughts in the comments below – I'd love to hear about your real-world experiences and lessons learned! 🚀

CSR vs SSR in Next.js

Khaled Saeed — Fri, 18 Jul 2025 10:02:40 +0000

CSR vs SSR in Next.js: From Basics to Advanced Implementation

Introduction

When building modern web applications with Next.js, one of the most crucial decisions you'll make is choosing the right rendering strategy. Client-Side Rendering (CSR) and Server-Side Rendering (SSR) each have their strengths and use cases. This guide will walk you through everything you need to know about CSR vs SSR in Next.js.

What is Rendering?

Rendering is the process of converting your React components into HTML that can be displayed in the browser.

Next.js supports multiple rendering methods:

CSR (Client-Side Rendering)
SSR (Server-Side Rendering)
SSG (Static Site Generation)
ISR (Incremental Static Regeneration)

But let’s focus on CSR and SSR.

What is CSR?

Client-Side Rendering (CSR) is a rendering approach where the initial HTML sent to the browser is minimal, and JavaScript running in the browser generates the content dynamically.

How CSR Works:

What is SSR?

Server-Side Rendering (SSR) is a rendering approach where the HTML is generated on the server for each request, then sent to the browser as a fully-formed page.

How SSR Works:

Key Differences

Aspect	CSR	SSR
Initial Load	Slower (JavaScript must load first)	Faster (HTML ready immediately)
SEO	Poor (content loaded via JS)	Excellent (content in HTML)
Server Load	Lower	Higher
Subsequent Navigation	Faster	Slower
User Experience	Blank page → Content appears	Content appears immediately
Caching	Easier to cache assets	More complex caching

Code Examples

Client-Side Rendering Example

// pages/csr-example.js
import { useState, useEffect } from 'react';

function CSRExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // This runs only on the client
    fetch('/api/data')
      .then(response => response.json())
      .then(data => {
        setData(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;

  return (
    <div>
      <h1>Client-Side Rendered Page</h1>
      <p>Data: {data?.message}</p>
    </div>
  );
}

export default CSRExample;

Server-Side Rendering Example

// pages/ssr-example.js
function SSRExample({ data }) {
  return (
    <div>
      <h1>Server-Side Rendered Page</h1>
      <p>Data: {data.message}</p>
      <p>Generated at: {data.timestamp}</p>
    </div>
  );
}

// This function runs on the server for each request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: {
      data: {
        ...data,
        timestamp: new Date().toISOString()
      }
    }
  };
}

export default SSRExample;

Performance Comparison

Time to First Byte (TTFB)

CSR: Fast TTFB (but slower content rendering)
SSR: Slower (server processing time)

First Contentful Paint (FCP)

CSR: Slow (wait for JS execution)
SSR: Fast (HTML ready immediately)

Time to Interactive (TTI)

CSR: Slow (dependent on JS bundle size)
SSR: Moderate (hydration required)

Performance Optimization Example

// pages/optimized-ssr.js
import dynamic from 'next/dynamic';

// Lazy load heavy components
// ! `ssr: false` turns the component into a client component.
const HeavyComponent = dynamic(() => import('../components/HeavyComponent'), {
  loading: () => <p>Loading...</p>,
  ssr: false // Disable SSR for this component
});

function OptimizedSSR({ criticalData }) {
  return (
    <div>
      <h1>Optimized SSR Page</h1>
      <div>Critical content: {criticalData.message}</div>

      {/* This component loads only on client */}
      <HeavyComponent />
    </div>
  );
}

export async function getServerSideProps() {
  // Only fetch critical data on server
  const res = await fetch('https://api.example.com/critical-data');
  const criticalData = await res.json();

  return {
    props: {
      criticalData
    }
  };
}

export default OptimizedSSR;

When to Use What

Use CSR When:

Building a dashboard or admin panel
User interaction is frequent
SEO is not a priority
You need real-time updates
Building a Single Page Application (SPA)

Use SSR When:

SEO is crucial
First-page load performance matters
Content changes frequently
Building e-commerce sites
Social media sharing is important

Advanced Topics

Dynamic Imports for Code Splitting

// Advanced code splitting example
import dynamic from 'next/dynamic';
import { useState } from 'react';

const DynamicChart = dynamic(() => import('../components/Chart'), {
  loading: () => <p>Loading chart...</p>,
  ssr: false
});

const DynamicTable = dynamic(() => import('../components/Table'), {
  loading: () => <p>Loading table...</p>
});

function AdvancedCSR() {
  const [view, setView] = useState('chart');

  return (
    <div>
      <nav>
        <button onClick={() => setView('chart')}>Chart View</button>
        <button onClick={() => setView('table')}>Table View</button>
      </nav>

      {view === 'chart' && <DynamicChart />}
      {view === 'table' && <DynamicTable />}
    </div>
  );
}

Streaming SSR (React 18+)

// pages/streaming-ssr.js
import { Suspense } from 'react';

function SlowComponent() {
  // Simulate slow component
  await new Promise((res) => setTimeout(res, 3000));
  return <div>Slow loading content</div>;
}

function StreamingSSR() {
  return (
    <div>
      <h1>Streaming SSR Example</h1>
      <p>This content loads immediately</p>

      <Suspense fallback={<div>Loading slow content...</div>}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

export default StreamingSSR;

Edge-Side Rendering with Middleware

// middleware.js
import { NextResponse } from 'next/server';

export function middleware(request) {
  const country = request.geo?.country || 'US';

  // Customize response based on location
  const response = NextResponse.next();
  response.headers.set('x-country', country);

  return response;
}

export const config = {
  matcher: '/api/:path*'
};

// Note: Middleware runs before requests but cannot render HTML. it's useful for things like redirects, geolocation, or A/B testing logic.

Best Practices

1. Choose the Right Rendering Strategy

// Decision matrix in code
const getRenderingStrategy = (pageType, requirements) => {
  if (requirements.seo && requirements.freshData) {
    return 'SSR';
  }

  if (requirements.interactivity && !requirements.seo) {
    return 'CSR';
  }

  return 'Hybrid';
};

2. Optimize Bundle Size

// next.config.js
module.exports = {
  experimental: {
    css: true,
  },
  webpack: (config) => {
    config.optimization.splitChunks.chunks = 'all';
    return config;
  }
};

3. Implement Progressive Enhancement

// Progressive enhancement example
function ProgressiveForm() {
  const [isClient, setIsClient] = useState(false);

  useEffect(() => {
    setIsClient(true);
  }, []);

  return (
    <form>
      <input type="text" name="name" required />
      <input type="email" name="email" required />

      {/* Enhanced features only on client */}
      {isClient && (
        <div>
          <AutoComplete />
          <RealTimeValidation />
        </div>
      )}

      <button type="submit">Submit</button>
    </form>
  );
}

4. Error Handling and Loading States

// Comprehensive error handling
function RobustSSR({ data, error }) {
  if (error) {
    return <ErrorComponent error={error} />;
  }

  return (
    <div>
      <h1>Robust SSR Page</h1>
      <p>{data?.message}</p>
    </div>
  );
}

export async function getServerSideProps() {
  try {
    const res = await fetch('https://api.example.com/data');

    if (!res.ok) {
      throw new Error('Failed to fetch data');
    }

    const data = await res.json();

    return {
      props: { data }
    };
  } catch (error) {
    return {
      props: {
        error: error.message
      }
    };
  }
}

Conclusion

Choosing between CSR and SSR in Next.js isn't about picking one over the other, it's about understanding your application's requirements and users needs. Here's a quick recap:

Use SSR for SEO-critical pages and better initial load performance
Use CSR for highly interactive applications where SEO isn't a priority

Next.js makes it easy to implement any of these strategies, and you can even mix them within the same application. The key is to profile your application, understand your users' journey, and choose the rendering strategy that provides the best user experience.

Remember: Performance is not just about fast loading, it's about the right content being available at the right time for your users.

📚 Further Reading: Server and Client Components

✨Mood-based Travel Poster Generator✈️

Khaled Saeed — Fri, 11 Jul 2025 22:27:13 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I built a Mood-based Travel Poster Generator, an AI-powered app that creates unique travel posters based on the user's current mood. I used this prompt in Google AI Studio:

"Build a web app that take the user current mood. Based on the mood, the app suggests a matching travel destination and generates a travel poster using Imagen. The image should reflect both the emotion and the destination’s essence (e.g., 'melancholic' → rainy Venice; 'curious' → ancient ruins in Peru). Include a 'Regenerate Poster' button to create a new variation. Add a simple UI with a text input and a dropdown of mood presets."

Demo

My Experience

This project was a great exercise in blending creativity and technical design. I learned how to:

Structure prompts for more stylized image outputs
Use the Imagen API effectively for emotion-to-visual mapping

Thanks to Google AI Studio and DEV for making this learning experience fun and creative!

Automatically Set Access Tokens in Postman After Login (No More Copy-Paste)

Khaled Saeed — Mon, 07 Jul 2025 08:44:20 +0000

Automatically Set Access Tokens in Postman After Login (No More Copy-Paste!)

If you're working with APIs that use access tokens (like JWTs), you've probably dealt with the annoying routine:

Send a POST /login request
Copy the access token from the response
Paste it into the Authorization header of every other request

😩 Repeating this every time the token expires gets old fast.

🚀 What if you could automate it?

This guide shows you how to extract the token automatically after login and set it as a dynamic environment variable in Postman. Then you can reuse it in any request, no manual copying needed!

📦 Step 1: Create or Select a Postman Environment

Click New Environment in the top right of Postman
Add a new environment (e.g., Local API)
Add a variable called accessToken, set the type to secret, and leave the initial value empty

🧪 Step 2: Add a Script to Your Login Request

In your POST /api/v1/auth/login request, go to the Scripts section, then select the Post-response tab and add this:

const res = pm.response.json();

if (res.success && res.data && res.data.accessToken) {
    pm.environment.set("accessToken", res.data.accessToken);
    console.log("✅ accessToken saved to environment");
} else {
    console.log("❌ Failed to extract accessToken");
}

💬 What does this script do?

It parses the JSON response returned from your login request.
It checks if the response contains a valid accessToken.
If so, it stores the token in your environment as accessToken, making it available across all your other API requests.
You’ll see a confirmation in the Postman console.

You can also save more fields if needed:

pm.environment.set("refreshToken", res.data.refreshToken);
pm.environment.set("userId", res.data.user.id);

🧷 Step 3: Use the Token in Other Requests

Once the accessToken is saved as an environment variable, you can inject it automatically into your other requests.

✅ Option 1: Use the Authorization Tab

In your API request, go to the Authorization tab
Select Bearer Token for the Auth Type
Set the token to {{accessToken}}

✅ Option 2: Set the Header Manually

Instead of using the Authorization tab, you can manually add a header:

Authorization: Bearer {{accessToken}}

That’s it! Now your token will automatically update after each login and be used wherever {{accessToken}} is referenced.

🎁 Bonus: Automate Token Refresh (Optional)

If your API provides a refreshToken flow (e.g., POST /refresh-token), you can automate that too!

Create a separate request for refreshing the token, and add a Post-response script:

const res = pm.response.json();

if (res.newAccessToken) {
    pm.environment.set("accessToken", res.newAccessToken);
    console.log("🔄 accessToken refreshed and updated");
}

Then you can call this request manually or as a pre-request step if a 401 is detected.

🧠 Summary

Here’s what you’ve accomplished:

✅ Automatically saved your accessToken from the login response

✅ Injected the token into future requests using dynamic variables

✅ Removed the need for manually copying and pasting tokens

✅ Optionally prepared for refresh token logic

🏁 Conclusion

This small but powerful automation trick can save you a lot of time, especially when working with authenticated APIs during development or testing.

No more expired tokens or constant back-and-forth between tabs!

Let me know if you’d like a follow-up guide on chaining token refresh logic or fully automating session flows in Postman and I’d love to hear how you’re using Postman in your workflow.

Happy testing! 🙌