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, serverseitigesauth(), 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 Sievendor_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.