The front door to identity

Registration, authentication, and self-service built on ForgeRock — a Next.js front end driving a journey engine that was never designed to be pretty.

01/Context

ForgeRock drives authentication as a sequence of callbacks: the server decides what to ask next, the client renders it. That is flexible and it is also a good way to end up with an interface that leaks the state machine to the user. The work was a front end that follows the journey engine exactly while looking like one designed product.

02/Constraints

The server owns the flow: The client cannot assume a step order. Any screen can be followed by any other, including a step type it has not seen before.
Security posture: No token in local storage, no secrets in the bundle, no error message that tells an attacker which half of the credential was wrong.
Every user: It is the front door. It has to work on an old phone, with a screen reader, and on a slow connection.

03/Architecture

Callback rendering: Each ForgeRock callback type maps to a typed component through a single registry. An unknown callback renders a safe generic input instead of breaking the journey.
Session handling: OIDC with tokens held in httpOnly cookies; the browser never sees them. Refresh happens behind a single client boundary rather than scattered through the app.
Accessibility: Real form semantics, focus moved deliberately on every step change, and errors announced rather than only coloured.

04/Outcome

One component registry covers the whole journey catalogue — a new step type is configuration, not a release.
The identity team reorders journeys without waiting on front-end work.
Keyboard and screen-reader paths are part of the definition of done, not a later fix.

All case studies Next — Tooling that writes the boring half