> ## 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.

# Guida rapida Next.js per l'autenticazione

> Pianifica una sessione di autenticazione gestita lato server con callback PKCE, cookie HttpOnly e autorizzazione sulle richieste protette con Didit.

> [!WARNING]
>
> Authentication è una novità: `@didit-protocol/auth-nextjs` e il verificatore core lato server dipendono dalla release. Prima del rilascio del pacchetto non sono prescritti né un percorso di import per il middleware né un nome di cookie né una forma di ritorno di `auth()`. I token di accesso sono JWT ES256: verificali con il JWKS della tua applicazione e chiama `GET session/` quando devi sapere se la sessione è ancora attiva.

## Mantieni la sessione sul tuo server

Usa il flusso ospitato descritto nella [guida rapida JavaScript](https://docs.didit.me/it/authentication/quickstarts/javascript.md), con le seguenti modifiche per un'applicazione con rendering lato server. Le route che definisci sono route dell'applicazione che implementi tu, non endpoint dell'API di Didit.

| Route dell'applicazione | Responsabilità |
| - | - |
| Avvio dell'accesso | Genera state e PKCE S256; memorizza la transazione in una sessione server di breve durata; reindirizza a `{origin}/sign-in`. |
| Callback registrata | Valida state e scadenza, consuma la transazione una sola volta, scambia il codice presso `token/` e memorizza i token lato server. |
| Pagina o route API protetta | Leggi il cookie di sessione e verifica il token di accesso dell'utente finale utilizzando il tuo JWKS oppure chiama `session/` quando la revoca deve essere immediata; autorizza l'azione richiesta per quella persona. |
| Aggiornamento | Serializza il refresh per sessione, chiama `token/` e sostituisci in modo atomico la coppia di token. |
| Disconnessione | Mutazione protetta da CSRF che revoca `session/` e cancella la sessione dell'applicazione. |

Invia soltanto un riferimento casuale alla sessione dell'applicazione, in un cookie `Secure`, `HttpOnly`, `SameSite=Lax` con percorso limitato. Usa una scadenza appropriata e ruota il riferimento dopo l'accesso. Non esporre il refresh token di Didit in props renderizzate, componenti client o storage del browser. Usa `Cache-Control: no-store` nelle risposte di token e callback.

Non affidarti soltanto a un controllo nel layout o nel middleware: autorizza a ogni accesso ai dati e a ogni mutazione. Proteggi le mutazioni autenticate tramite cookie contro CSRF. Consenti solo le destinazioni post-accesso configurate, mai un URL `returnTo` arbitrario proveniente dalla query string.

## Anteprima della release del pacchetto

Il pacchetto previsto aggiunge middleware, `auth()` lato server, una route di callback e il supporto ai cookie HttpOnly per il rendering lato server. Il punto di ingresso `/server` del core è pensato per fornire `verifyToken()` con JWKS in cache. Attendi gli export della release verificata prima di usare questi simboli. Fino ad allora, verifica tu i token con una qualsiasi libreria JOSE, come descritto in [token e JWKS](https://docs.didit.me/it/authentication/tokens-and-jwks.md).

## Collega gli altri prodotti

Crea le sessioni di verifica e genera sul server i token di monitoraggio con scope limitato. Ricava `vendor_data` dalla mappatura validata della persona. Restituisci al browser solo l'URL della sessione di verifica o un token SDK di breve durata. Tieni `DIDIT_API_KEY` fuori dalle variabili d'ambiente pubbliche.

Per la verifica usa l'[SDK di verifica web](https://docs.didit.me/it/integration/web-sdks/javascript-sdk.md) esistente e per il monitoraggio la [guida all'invio delle transazioni](https://docs.didit.me/it/transaction-monitoring/sdk-transaction-submission.md). Nessuno dei due è un gestore di sessioni di Authentication.

Prima del rilascio, testa il replay della callback, lo state errato, lo state scaduto, le race condition nel refresh, le sessioni revocate, il rifiuto CSRF e la disconnessione. Consulta [token e JWKS](https://docs.didit.me/it/authentication/tokens-and-jwks.md) per il contratto di validazione.


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