Refreshing Session Cookie Claims in Firebase Following User Email Verification

Handling Session Cookies and Email Verification with Firebase Authentication

Managing user authentication effectively becomes essential when creating web apps that prioritize server-side rendering and data fetching, such those created with NextJS and React Server Components. A strong solution is provided by utilizing session cookies in conjunction with Firebase Authentication, particularly for apps that need longer session durations. This method—which is described in Firebase's documentation—uses session cookies for authentication, extending sessions' duration beyond the default token ID lifespan to a maximum of 14 days. To ensure a safe and long-lasting user session, the implementation mints a session cookie from the user's token ID during login or sign-up and stores it as a HttpOnly cookie.

However, adding email verification is a hurdle for this strategy. The session cookie's email_verified field shows the user's unverified status even after they join up with an email address and password and validate it via a link. The reason for this disparity is that, once established, the session cookie is not updated immediately to take into account modifications to the user's authentication status, like email verification. To solve this problem, a method that permits session cookie refreshes or updates without jeopardizing security or user experience is needed, particularly in light of Firebase's constraints on token persistence and session management.

Knowing the Mechanism of Session Cookie Refresh

The included backend script makes use of the Firebase Admin SDK and Node.js to manage the critical task of updating a user's session cookie following email verification. In order to effectively handle HTTP cookies, this activity begins with configuring an Express.js server and integrating cookie-parser middleware. By initializing the Firebase app with server-side credentials, the admin.initializeApp() function allows the application to safely communicate with Firebase services. admin.auth() is used by a middleware method called checkAuth.To confirm the session cookie given with client requests, use the verifySessionCookie() function. To guarantee that only authenticated requests are sent to sensitive routes or activities, this verification is essential. The route '/refresh-session', which may be requested by any confirmed user, is the essential component of the script. The middleware authenticates the user in response to this request, and admin.auth().createCustomToken() is then used to build a new custom token. In order to create a new session cookie with updated claims—including the email verification status—this token is necessary.

In order to guarantee that there are no security issues and the user stays signed in, the freshly created session cookie is sent back to the client with an updated expiration time. The initial issue of the email_verified field not updating upon email verification is resolved by this procedure. A JavaScript snippet on the client side initiates the session refresh procedure. When a certain event, such clicking a button, is detected, it sends a GET request to the '/refresh-session' endpoint. Because it manages the network request and interprets the result, the get() function is essential in this situation. The client is informed and the page can be reloaded with the user's confirmed status reflected if the session refresh is successful. The difficulty of maintaining an updated and safe authentication state across client and server contexts is addressed by this solution, which guarantees a smooth user experience without forcing the user to actively reauthenticate or preserve the Token ID on the client side after sign up.

// Backend: Node.js with Firebase Admin SDK
const admin = require('firebase-admin');
const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();
app.use(cookieParser());
// Initialize Firebase Admin
admin.initializeApp({credential: admin.credential.applicationDefault()});
// Middleware to check authentication
const checkAuth = async (req, res, next) => {
  try {
    const sessionCookie = req.cookies.__session || '';
    const decodedClaims = await admin.auth().verifySessionCookie(sessionCookie, true);
    req.decodedClaims = decodedClaims;
    next();
  } catch (error) {
    res.status(401).send('Unauthorized');
  }
};
// Route to refresh session cookie
app.get('/refresh-session', checkAuth, async (req, res) => {
  const { uid } = req.decodedClaims;
  const newToken = await admin.auth().createCustomToken(uid);
  const expiresIn = 60 * 60 * 24 * 5 * 1000; // 5 days
  const sessionCookie = await admin.auth().createSessionCookie(newToken, { expiresIn });
  const options = { maxAge: expiresIn, httpOnly: true, secure: true };
  res.cookie('__session', sessionCookie, options);
  res.end('Session refreshed');
});
// Start the server
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

// Client-side: JavaScript to trigger session refresh
document.addEventListener('DOMContentLoaded', function() {
  const refreshButton = document.getElementById('refresh-session-button');
  refreshButton.addEventListener('click', async () => {
    try {
      const response = await fetch('/refresh-session', { method: 'GET' });
      if (response.ok) {
        alert('Session has been refreshed. Please reload the page.');
      } else {
        throw new Error('Failed to refresh session');
      }
    } catch (error) {
      console.error('Error:', error);
      alert('Error refreshing session. See console for details.');
    }
  });
});

Improving User Experience and Security Using Firebase Session Cookies

Applications developed using NextJS and React Server Components, in particular, necessitate a sophisticated understanding of session management and security in order to integrate Firebase authentication. For applications that need server-side rendering and longer user sessions, Firebase's session cookie approach is a strong substitute for conventional token-based authentication. Session cookies are preferred over token IDs because of their extended validity period—up to 14 days—which lowers the need for user re-authentications in contrast to token IDs' hourly refresh need. By preserving session continuity even in situations where the client is inactive for protracted periods of time, this method improves the user experience.

In addition to being convenient, session cookies that are set to HttpOnly provide an extra degree of protection by preventing client-side scripts from accessing them, reducing the possibility of cross-site scripting (XSS) attacks. But there are difficulties with this safe configuration, especially when it comes to upgrading the session cookie after a user's email verification. Developers must add a way to refresh or regenerate the session cookie because the cookie's lifespan and HttpOnly property prevent the email_verified claim from updating automatically upon email verification. This guarantees that access limits depending on the status of email verification may be properly enforced and that the user's authentication state is effectively reflected.