> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Next.js quickstart

> Plan a server-owned Authentication session with PKCE callbacks, HttpOnly cookies and authorization on protected requests.

<Warning>
  Early access: `@didit-protocol/auth-nextjs` and the core server verifier are release-dependent. No middleware import path, cookie name or `auth()` return shape is prescribed before the package release. The current runtime validates opaque tokens through `GET session/`.
</Warning>

## Keep the session on your server

Use the hosted flow described in the [JavaScript quickstart](/authentication/quickstarts/javascript), with the following changes for a server-rendered application. Your route names are application routes that you implement, not Didit API endpoints.

| Application route | Responsibility |
| - | - |
| Start sign-in | Generate state and S256 PKCE; store the transaction in a short-lived server session; redirect to the configured runtime's `sign-in/`. |
| Registered callback | Validate state and expiry, consume the transaction once, exchange the code at `token/`, and store tokens server-side. |
| Protected page or API route | Read your session cookie and validate the end-user token at `session/`; authorize the requested action for that person. |
| Refresh | Serialize refresh per session, call `token/`, and atomically replace the token pair. |
| Sign-out | CSRF-protected mutation that revokes `session/` and clears the application session. |

Send only a random application-session reference in a `Secure`, `HttpOnly`, `SameSite=Lax` cookie with a scoped path. Use an appropriate expiry and rotate the reference after sign-in. Do not expose the Didit refresh token in rendered props, client components or browser storage. Use `Cache-Control: no-store` on token and callback responses.

Do not rely on a layout or middleware check alone: authorize at each data access and mutation. Protect cookie-authenticated mutations against CSRF. Allow only configured post-login destinations, never an arbitrary `returnTo` URL from the query string.

## Package release preview

The planned package adds middleware, server-side `auth()`, a callback route and HttpOnly cookie support for server rendering. The core `/server` entry is intended to provide `verifyToken()` with cached JWKS. Wait for the verified release exports and issuer configuration before using these symbols; the current opaque token is not locally verifiable as a JWT.

## Connect the other products

Create verification sessions and mint scoped monitoring tokens on the server. Derive `vendor_data` from the validated person mapping. Return only a verification session URL or short-lived SDK token to the browser. Keep `DIDIT_API_KEY` out of public environment variables.

Use the existing [web verification SDK](/integration/web-sdks/javascript-sdk) for verification and [transaction submission guide](/transaction-monitoring/sdk-transaction-submission) for monitoring. Neither is an Authentication session manager.

Test callback replay, wrong state, expired state, refresh races, revoked sessions, CSRF rejection and logout before release. See [tokens and JWKS](/authentication/tokens-and-jwks) for the current and upcoming validation contracts.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.