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

Source: Dev.to

Introduction

I originally built a Next.js application that required a login feature. 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.

Architecture Overview

I wanted the application to follow Domain‑Driven Design (DDD) principles, so 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

Goals of the Separation

• Authentication should be reusable independently of the frontend technology.
• 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.

Next.js as a Bridge

Next.js runs both on the server and in the browser, creating a powerful shortcut:

1. Next.js calls the OAuth server server‑side.
2. It receives the JWT outside the browser.
3. It forwards that JWT to the client and stores it in a cookie.

From a developer perspective this feels elegant and simple. Architecturally, however, a subtle shift occurs: the frontend now participates 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

Next.js’s 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.

Benefits of Applying DDD

• Authentication logic lives outside the frontend instead of being buried inside a single framework.
• Responsibilities remain clear and boundaries explicit.
• The frontend can still leverage Next.js’s capabilities without coupling to authentication details.

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.

Repository

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

👉

The repository contains the standalone OAuth Express server that owns the Passport implementation and JWT issuance, exactly as described above. It’s designed to be reused across projects, independently of the frontend framework.