Saltar al contenido principal
La autenticación es nueva: @didit-protocol/auth-nextjs y el verificador de servidor principal dependen del lanzamiento del paquete. Hasta que se publique, no se establece ninguna ruta de importación del middleware, ningún nombre de cookie ni ninguna estructura de retorno de auth(). Los tokens de acceso son JWT ES256: verifícalos con el JWKS de tu aplicación y invoca GET session/ cuando necesites saber si la sesión sigue activa.

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én vendor_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.
Última modificación el 1 de noviembre de 2026