Zum Hauptinhalt springen
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 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. 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 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 zur Verifizierung und den Leitfaden zur Transaktionsübermittlung 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 für den Validierungsvertrag.
Zuletzt geändert am 7. November 2026