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

> Didit-Authentifizierung in Next.js mit serverseitigen Sitzungen, PKCE-Callbacks, HttpOnly-Cookies und Schutz für API-Anfragen einrichten.

> [!WARNING]
>
> Authentifizierung ist neu: `@didit-protocol/auth-nextjs` und der Core-Server-Verifier sind releaseabhängig. Vor der Paketveröffentlichung sind weder der Middleware-Importpfad, der Cookie-Name noch die Rückgabestruktur von `auth()` vorgegeben. Access-Tokens sind ES256-JWTs: Verifizieren Sie sie mit dem JWKS Ihrer Anwendung und rufen Sie `GET session/` auf, wenn Sie wissen müssen, ob die Sitzung noch aktiv ist.

## Sitzung auf Ihrem Server behalten

Verwenden Sie den gehosteten Ablauf, der im [JavaScript-Quickstart](https://docs.didit.me/de/authentication/quickstarts/javascript.md) beschrieben ist, mit den folgenden Änderungen für eine servergerenderte Anwendung. Bei Ihren Routennamen handelt es sich um Anwendungsrouten, die Sie selbst implementieren, nicht um Didit-API-Endpoints.

| Anwendungsroute | Zuständigkeit |
| - | - |
| Anmeldung starten | State und S256-PKCE generieren; Transaktion in einer kurzlebigen Serversitzung speichern; Weiterleitung zu `{origin}/sign-in`. |
| Registrierter Callback | State und Ablaufdatum validieren, Transaktion einmalig verwenden, den Code über `token/` austauschen und Tokens serverseitig speichern. |
| Geschützte Seite oder API-Route | Ihr Sitzungs-Cookie auslesen und das Access-Token des Endbenutzers gegen Ihr JWKS oder über `session/` verifizieren, falls der Widerruf sofort erfolgen muss; die angeforderte Aktion für diese Person autorisieren. |
| Refresh | Refresh pro Sitzung serialisieren, `token/` aufrufen und das Token-Paar atomar ersetzen. |
| Abmeldung | CSRF-geschützte Mutation, die `session/` widerruft und die Anwendungssitzung löscht. |

Senden Sie nur eine zufällige Anwendungssitzungs-Referenz in einem `Secure`-, `HttpOnly`-, `SameSite=Lax`-Cookie mit einem auf einen bestimmten Pfad begrenzten Geltungsbereich. Verwenden Sie ein angemessenes Ablaufdatum und rotieren Sie die Referenz nach der Anmeldung. Legen Sie das Didit-Refresh-Token niemals in gerenderten Props, Client-Komponenten oder im Browser-Speicher offen. Verwenden Sie `Cache-Control: no-store` für Token- und Callback-Antworten.

Verlassen Sie sich nicht allein auf eine Layout- oder Middleware-Prüfung: Autorisieren Sie bei jedem Datenzugriff und jeder Mutation. Schützen Sie Cookie-authentifizierte Mutationen gegen CSRF. Erlauben Sie nur konfigurierte Ziele nach der Anmeldung, niemals eine beliebige `returnTo`-URL aus dem Query-String.

## Vorschau auf das Paket-Release

Das geplante Paket ergänzt Middleware, serverseitiges `auth()`, eine Callback-Route und HttpOnly-Cookie-Unterstützung für Server-Rendering. Der Core-Einstiegspunkt `/server` soll `verifyToken()` mit zwischengespeichertem JWKS bereitstellen. Warten Sie auf die verifizierten Release-Exporte, bevor Sie diese Symbole verwenden. Bis dahin können Sie Tokens mit einer beliebigen JOSE-Bibliothek selbst verifizieren, wie unter [Tokens und JWKS](https://docs.didit.me/de/authentication/tokens-and-jwks.md) beschrieben.

## Weitere Produkte anbinden

Erstellen Sie Verifizierungssitzungen und generieren Sie berechtigungseingeschränkte Monitoring-Tokens auf dem Server. Leiten Sie `vendor_data` aus dem validierten Personen-Mapping ab. Geben Sie nur eine Verifizierungssitzungs-URL oder ein kurzlebiges SDK-Token an den Browser zurück. Halten Sie `DIDIT_API_KEY` von öffentlichen Umgebungsvariablen fern.

Verwenden Sie das bestehende [Web-Verifizierungs-SDK](https://docs.didit.me/de/integration/web-sdks/javascript-sdk.md) zur Verifizierung und den [Leitfaden zur Transaktionsübermittlung](https://docs.didit.me/de/transaction-monitoring/sdk-transaction-submission.md) für das Monitoring. Keines von beiden ist ein Sitzungsmanager für die Authentifizierung.

Testen Sie Callback-Replays, fehlerhafte States, abgelaufene States, Refresh-Race-Conditions, widerrufene Sitzungen, CSRF-Zurückweisungen und den Logout vor der Veröffentlichung. Siehe [Tokens und JWKS](https://docs.didit.me/de/authentication/tokens-and-jwks.md) für den Validierungsvertrag.


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