Saltar al contenido principal
Autenticación es una función nueva. Didit activa el producto para tu aplicación. Hasta entonces, todas las rutas de tiempo de ejecución de esa aplicación devuelven 404. Los paquetes del SDK de Autenticación aún no están publicados, así que usa el flujo alojado y el contrato HTTP que se describen en estas páginas.
Autenticación permite que tus clientes inicien sesión en tu aplicación. Es independiente del inicio de sesión en la consola de Didit y de la creación de una cuenta de desarrollador de Didit. También es independiente de la verificación de la identidad de una persona. Usa Autenticación por sí sola o combínala con Verificación de identidad y Monitorización de transacciones. Iniciar sesión no aprueba una verificación ni autoriza un pago. Tu backend toma esas decisiones a partir del resultado propio de cada producto.

​
Cómo funciona

Cada aplicación tiene su propio origen de inicio de sesión y su propio emisor de tokens. Las aplicaciones de producción y las de sandbox son independientes: tienen orígenes, configuración e identidades separados. El flujo es OAuth 2.0 con código de autorización y PKCE (solo S256):
  1. Tu aplicación abre {origin}/sign-in con redirect_uri, state, code_challenge y code_challenge_method=S256.
  2. La página alojada permite a la persona iniciar sesión o registrarse con los métodos que activaste, incluido cualquier segundo factor obligatorio.
  3. El navegador vuelve a tu redirect_uri con code y state.
  4. Tu aplicación intercambia el código en POST {origin}/token/ por un token de acceso, un token de ID y un token de actualización.
Consulta tokens y JWKS para conocer el contrato de los tokens y métodos de inicio de sesión para cada método.

​
Elige tu plataforma

JavaScript

Inicio de sesión alojado, callback, sesión y cierre de sesión.

React

Estado del cliente y vistas protegidas de la aplicación.

Next.js

Sesiones de servidor, rutas de callback y cookies.

iOS

Navegador del sistema y almacenamiento seguro de tokens.

Android

Autorización en el navegador y callbacks de la aplicación.

React Native

Preparación del wrapper nativo de autenticación.

Flutter

Preparación del wrapper nativo de autenticación.

​
Prepara tu aplicación

  1. Pide a Didit que active Autenticación para tu aplicación. Prueba primero en una aplicación de sandbox.
  2. Registra tus URL de redirección exactas (hasta 50) y los allowed_origins del navegador (hasta 50) que llaman a la API de tiempo de ejecución.
  3. Activa los métodos de inicio de sesión que quieras ofrecer. Didit ID Wallet está siempre activado.
  4. Elige la configuración de sesión y de contraseña (ver más abajo).
  5. Prueba el registro, el inicio de sesión, la recuperación de contraseña, la MFA, la caducidad de la sesión y el cierre de sesión antes de pasar a producción.
Una passkey pertenece a su origen. Si más adelante activas un dominio personalizado, las personas deberán registrar sus passkeys de nuevo.

​
URL de redirección

Didit solo redirige a una persona a una dirección que hayas registrado. Registra las tuyas en la consola, en Authentication > Security and sessions > Redirect URLs and allowed origins. El redirect_uri de una solicitud de inicio de sesión debe coincidir carácter por carácter con una URL registrada: esquema, host, puerto, ruta y query. Un puerto distinto, una barra final o una diferencia entre mayúsculas y minúsculas constituyen una dirección distinta. Se rechazan los comodines, los fragmentos, las credenciales en la URL y los esquemas personalizados. Cuando la dirección no está registrada, Didit nunca redirige a ella. {origin}/sign-in responde 400 con una página que indica qué registrar y dónde, y POST {origin}/authorize/ responde 400 {"error": "invalid_redirect_uri"}.

​
Desarrollo local

Prueba en tu propio equipo con tu aplicación de sandbox:
  1. Registra tu callback con su puerto, por ejemplo http://localhost:3000/auth/callback.
  2. Si el código del navegador llama a la API en tiempo de ejecución, por ejemplo para intercambiar el código en POST {origin}/token/, añade también el origen en Orígenes permitidos: http://localhost:3000, sin ruta y sin barra final.
  3. Inicia el inicio de sesión en tu origen de sandbox, https://<slug>.sandbox.auth.didit.me, con tu clave pk_test_....
localhost, 127.0.0.1 y [::1] son direcciones distintas, y también lo es cada puerto. Registra cada una que uses. Las aplicaciones de producción nunca aceptan http://. Antes de pasar a producción, registra tu callback https:// de producción en tu aplicación de producción.

​
Configuración de la aplicación

Gestionas esta configuración en la consola o con una sesión de consola autorizada que tenga write:authentication.

​
Mantener una misma persona en todos los productos

Cada identidad tiene un valor vendor_data. Es el external_id que proporcionaste al importar a la persona o, en caso contrario, el ID de identidad de Didit. Aparece en el token de acceso, en el ID token y en GET session/. Usa el mismo valor como vendor_data cuando crees sesiones de verificación y envíes transacciones. Así, los eventos de autenticación se asocian en la consola a la misma persona a la que pertenecen sus verificaciones y transacciones. Consulta eventos y webhooks. Obtén vendor_data en tu backend a partir de un token verificado, nunca de un campo del navegador sin comprobar. Usa el prompt de integración compartido para cualquier combinación. Lee protección contra bots para conocer las políticas que se aplican al iniciar sesión.
Última modificación el 1 de noviembre de 2026