Login Is Easy. Reusing It Isn’t

How the Same OAuth Architecture Powers Next.js and Embedded Widgets

Authentication is rarely the hard part.

Most modern stacks can implement a login flow using Passport, OAuth, and JWT in a matter of hours. Where systems start to break down is when that login needs to live beyond a single application.

This article compares two real implementations that use the same authentication core, yet operate in very different UI environments:

  • A Next.js application
  • An isolated, embeddable widget architecture (ReactEdge)

The goal is not to compare frameworks, but to show what actually changes — and what doesn’t — when UI boundaries move.

The shared authentication core

Both implementations rely on the same two backend components: a Keystone backend (data, users, session validity) and a standalone OAuth Express server owning Passport and JWT issuance.
These components are unchanged whether the UI is a full Next.js app or an embedded widget.

👉 If you want a detailed walkthrough of this setup in a Next.js context, it’s covered in depth here:
Implementing Login in a Next.js App with Passport, JWT, and DDD

That article explains why Next.js makes this architecture feel straightforward.

Reusing the same OAuth and backend authentication services across different UI boundaries by introducing a thin domain-level auth bridge.

Reusing the same OAuth and backend authentication services across different UI boundaries by introducing a thin domain-level auth bridge.

When the UI owns the delivery boundary

In a Next.js application, the frontend can temporarily act server-side, receive the JWT from OAuth, and persist it as a cookie before the response reaches the browser.
This makes login feel simple, but it only works because the UI controls the delivery boundary.

When the UI no longer owns the boundary

An embedded widget runs entirely in the browser and does not control the domain or HTTP response lifecycle.
As a result, it cannot safely store JWTs or write cookies directly, even though authentication itself still succeeds server-side.

The bridge that enables reuse

To solve this, a thin Express bridge is introduced on the same domain as the widget, responsible only for cookie storage and request forwarding.
This single addition allows both Keystone and OAuth to be reused unchanged, demonstrating that the authentication core survives UI changes without redesign.