OAuth Login Flow with Vite

Herve Tribouilloy — Sat, 07 Feb 2026 15:27:29 +0000

This article illustrates an implementation of an OAuth login flow using Vite as a JavaScript frontend. It highlights a server-side solution required to securely persist the session cookie when working with a pure client-side framework like Vite.

The example uses Google as the login provider and Passport to handle authentication.

Below is a snapshot of the core components involved in the OAuth flow and how responsibilities are split between them.

Although the OAuth flow above is well known, I discovered a practical limitation when using Vite.

Because a Vite application is a static frontend that runs entirely in the browser, it cannot handle a JWT server-side or create an HTTP-only session cookie. Establishing a secure session therefore requires a server that can receive the token and set the cookie in the HTTP response.

To handle this, I currently use a thin Express service that receives the JWT and sets it as a secure cookie before redirecting the user back to the Vite application.

The essential requirement is the domain: the server that sets the cookie must share the same parent domain as the Vite host. For example, a service running on auth.reactedge.net can set a cookie for .reactedge.net, which will then be sent automatically to wpdemo.reactedge.net.

The GitHub repository contains the flow illustrated here:

https://github.com/digitalrisedorset/bookme

The oauth-express folder implements the Google OAuth strategy. After successful authentication, it creates a JWT and synchronises the user with the backend.

The auth-bridge is the thin Express service that receives this JWT, sets it as a secure HTTP-only cookie for the browser, and then redirects the user back to the Vite frontend. This allows the session to persist without exposing the token to client-side code.

Implementing Login in a Next.js App with Passport, JWT, and DDD

Herve Tribouilloy — Sun, 01 Feb 2026 10:01:14 +0000

Introduction

I originally built a Next.js application that required a login feature.
From the start, I wanted this login to support OAuth to improve user convenience and avoid reinventing authentication flows.

To do this properly, I chose Passport (a well-established authentication library) and used JWTs as the security artefact for authenticated identity.

So far, this is fairly standard.

A deliberate DDD split

Where this became interesting is that I wanted the application to follow Domain-Driven Design (DDD) principles.

Instead of letting authentication live “wherever it was convenient”, I explicitly split the system into three components:

Backend Responsible for data persistence and business rules (API / GraphQL, user model, permissions, session validity)
OAuth Express server A custom Express server that owns Passport entirely (strategies, login orchestration, token issuance)
Frontend A Next.js application responsible only for UI and user interaction

OAuth Express server
A custom Express server that owns Passport entirely
(strategies, login orchestration, token issuance)

This separation had a very clear goal:

Authentication should be reusable independently of the frontend technology.

With this setup:

The frontend could change
The backend could change
OAuth could be reused across projects
without rewriting the login logic or coupling Passport to a specific UI framework.

So far, this architecture worked well.

The subtle convenience of Next.js

Next.js, however, has a unique property:

It runs both on the server and in the browser.

This creates a powerful shortcut.

In this architecture:

Next.js can call the OAuth server server-side
Receive the JWT outside the browser
Then forward that JWT to the client and store it in a cookie

From a developer perspective, this feels elegant and simple.

But architecturally, something subtle is happening:

The frontend is now participating in authentication storage.

Even though Passport lives elsewhere, Next.js becomes part of the trust boundary, because it:

receives the JWT server-side
decides how it is persisted in the browser

Conclusion

Next.js is a powerful environment.

Its ability to run code both server-side and client-side makes it well suited for implementing authentication flows. In this architecture, Next.js can safely receive a JWT on the server and persist it in the browser as a cookie within a single execution path.

By applying Domain-Driven Design, authentication logic lives outside the frontend instead of being buried inside a single framework. This keeps responsibilities clear and boundaries explicit, while still allowing the frontend to take advantage of Next.js’s capabilities.

The important takeaway is that the login feature is only part of the result. By separating concerns, two out of three components can now be reused unchanged in another project — something I’ll explore in a follow-up article.

If you’d like to explore this architecture in practice, the OAuth component described in this article is available as a public repository:

👉 https://github.com/digitalrisedorset/oauth-signin