Configura el inicio de sesión alojado
Registra la URL de callback exacta y tu origen web para tu aplicación de sandbox. Copia su origen de inicio de sesión (https://<slug>.sandbox.auth.didit.me) desde la consola, como se describe en la visión general. Este ejemplo usa las API de criptografía del navegador y requiere HTTPS, o localhost en sandbox: consulta desarrollo local para saber qué registrar.
La aplicación gestiona state y el verificador PKCE. El inicio de sesión alojado gestiona las pantallas de contraseña, correo electrónico, passkey, teléfono, SSO y MFA obligatoria. Ninguna clave de API debe estar en este código.
auth.js
signIn() desde tu botón de inicio de sesión. En la página de callback registrada, llama a handleCallback() una sola vez, muestra un estado de carga y muestra su error si falla. Usa getSession() para obtener el usuario actual y signOut() para cerrar la sesión. El callback elimina su código de la barra de direcciones antes de hacer una solicitud.
Este ejemplo mínimo guarda los tokens en memoria y vuelve a iniciar sesión tras recargar la página o cuando caduca el token de acceso. Para sesiones persistentes, usa tu backend y cookies seguras, o implementa una rotación de refresh tokens serializada. Nunca pongas refresh tokens en URL ni en logs. Una comprobación de sesión en el frontend solo controla la presentación; tu backend debe validar a quien llama en cada solicitud protegida.
Vista previa de la versión del SDK de autenticación
El núcleo previsto de@didit-protocol/auth expone createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange y signOut(), con vendorData en la identidad. Está previsto que añada señales de dispositivo automáticas y un punto de entrada de servidor con verifyToken().
La clave publicable es pk_live_ (aplicación de producción) o pk_test_ (aplicación de sandbox) seguida de la codificación base64url, sin relleno, del origen de tu aplicación.
El SDK envía sus llamadas a la API a ese origen.
La clave es pública: identifica la aplicación y no es un secreto.
Step-up y reautenticación en la vista previa
stepUp({ action, amount?, currency?, redirectUri? })invoca el endpointPOST step-up/de tu aplicación para preguntar siactionnecesita una comprobación de identidad.actionespayout,bankocontact, y un pago necesitaamount. Cuando se aplica una de tus reglas de step-up, navega a la página de verificación que devuelve Didit.handleStepUpCallback(url?)se ejecuta en la página a la que vuelve la persona. Lee?step_up=<id>, lo elimina de la barra de direcciones y lee el resultado conGET step-up/{id}/.reauthenticate({ method? })vuelve a iniciar la sesión de la misma persona, en la página alojada (method: "redirect", el valor predeterminado) o con una passkey (method: "passkey", solo en el dominio de inicio de sesión de Didit de tu aplicación). Después de la página alojada, complétalo conhandleRedirectCallback(). Si lo completa otra persona, se rechaza constep_up_user_mismatchy la sesión original se mantiene.
{ id, status, approved, rule, method }, donde status es not_required, pending, approved, review, declined o expired.
redirectUri toma por defecto la URL de redirección del cliente y debe coincidir exactamente con una de las URL de redirección registradas de tu aplicación: cuando se requiere una comprobación, Didit rechaza cualquier otra dirección.
Antes de que tu backend procese un step-up, vuelve a leer el step-up con GET step-up/{id}/ y el token de acceso de la persona, porque un resultado informado por el navegador puede alterarse.
Un inicio de sesión headless también puede devolver protection_required cuando las reglas de protección de tu aplicación lo marcan.
La persona lo completa entonces con el código que Didit le envió por correo electrónico (protection.verify({ code })) o con una passkey (protection.passkey()), y methods indica cuál de las dos puede usar.
No instales una versión sin confirmar ni escribas código basado en opciones de callback sin confirmar. Confirma las exportaciones del paquete publicado, el emisor y la configuración de claves antes de sustituir el ejemplo alojado. Los métodos de contraseña, código por correo electrónico, enlace mágico, passkey, teléfono, MFA, inicio de sesión social, step-up y agentes dependerán de la API compatible con esa versión.
Añade otros productos
Tu backend verifica el token de acceso (consulta tokens y JWKS) y lee suvendor_data. Usa ese valor como vendor_data al crear una sesión de verificación o al emitir un token de transacción. Un inicio de sesión correcto no implica que ninguno de los dos productos haya aprobado al usuario.
Antes de publicar, prueba el registro, el inicio de sesión de usuarios recurrentes, la cancelación, el state que no coincide, el código reutilizado, la contraseña olvidada, MFA, la caducidad y el cierre de sesión con tu aplicación de sandbox habilitada.