Mantén la sesión en tu servidor
Usa el flujo alojado que se describe en la guía rápida de JavaScript, con los siguientes cambios para una aplicación renderizada en el servidor. Los nombres de tus rutas son rutas de la aplicación que implementas tú, no endpoints de la API de Didit.
Envía solo una referencia aleatoria a la sesión de la aplicación en una cookie
Secure, HttpOnly, SameSite=Lax con una ruta de alcance limitado. Usa una caducidad adecuada y rota la referencia después del inicio de sesión. No expongas el token de renovación de Didit en props renderizadas, componentes de cliente ni almacenamiento del navegador. Usa Cache-Control: no-store en las respuestas de tokens y de callback.
No te limites a una comprobación en un layout o en el middleware: autoriza en cada acceso a datos y en cada mutación. Protege contra CSRF las mutaciones autenticadas con cookies. Permite solo los destinos de redirección posteriores al inicio de sesión que hayas configurado, nunca una URL returnTo arbitraria procedente de la query string.
Vista previa de la publicación del paquete
El paquete previsto añade middleware,auth() en el servidor, una ruta de callback y compatibilidad con cookies HttpOnly para el renderizado en el servidor. Está previsto que el punto de entrada principal /server ofrezca verifyToken() con JWKS en caché. Espera a las exportaciones de la versión verificada antes de usar estos símbolos. Mientras tanto, verifica los tokens tú mismo con cualquier biblioteca JOSE, como se describe en tokens y JWKS.
Conecta los demás productos
Crea las sesiones de verificación y emite tokens de monitorización con alcance limitado en el servidor. Obténvendor_data a partir de el mapeo de la persona validada. Devuelve al navegador solo una URL de sesión de verificación o un token de SDK de corta duración. Mantén DIDIT_API_KEY fuera de las variables de entorno públicas.
Usa el SDK de verificación web existente para la verificación y la guía de envío de transacciones para la monitorización. Ninguno de los dos es un gestor de sesiones de Authentication.
Antes de publicar, prueba la reproducción del callback, un state incorrecto, un state expirado, las condiciones de carrera en la renovación, las sesiones revocadas, el rechazo por CSRF y el cierre de sesión. Consulta tokens y JWKS para conocer el contrato de validación.