> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Autenticación de usuario final, passkeys y sesiones > Didit añade inicio de sesión para usuarios finales con páginas alojadas, passkeys, códigos, login social y SSO, conectado a verificación y monitorización. > [!WARNING] > > 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. | Elemento | Valor | | - | - | | Origen predeterminado | `https://.auth.didit.me` para una aplicación de producción, `https://.sandbox.auth.didit.me` para una aplicación de sandbox. La consola muestra el tuyo. Un dominio personalizado verificado puede sustituirlo. | | Páginas alojadas | `/sign-in`, `/magic`, `/invite` y `/reset` en ese origen. | | API de tiempo de ejecución | El mismo origen, por ejemplo `POST {origin}/token/` y `GET {origin}/session/`. | | Emisor | El propio origen. El descubrimiento está en `{origin}/.well-known/openid-configuration`. | | Clave publicable | `pk_live_...` o `pk_test_...`. Identifica la aplicación; no es un secreto. | 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](https://docs.didit.me/es/authentication/tokens-and-jwks.md) para conocer el contrato de los tokens y [métodos de inicio de sesión](https://docs.didit.me/es/authentication/sign-in-methods.md) para cada método. ## Elige tu plataforma > [card] [JavaScript](https://docs.didit.me/es/authentication/quickstarts/javascript.md) > > Inicio de sesión alojado, callback, sesión y cierre de sesión. > [card] [React](https://docs.didit.me/es/authentication/quickstarts/react.md) > > Estado del cliente y vistas protegidas de la aplicación. > [card] [Next.js](https://docs.didit.me/es/authentication/quickstarts/nextjs.md) > > Sesiones de servidor, rutas de callback y cookies. > [card] [iOS](https://docs.didit.me/es/authentication/quickstarts/ios.md) > > Navegador del sistema y almacenamiento seguro de tokens. > [card] [Android](https://docs.didit.me/es/authentication/quickstarts/android.md) > > Autorización en el navegador y callbacks de la aplicación. > [card] [React Native](https://docs.didit.me/es/authentication/quickstarts/react-native.md) > > Preparación del wrapper nativo de autenticación. > [card] [Flutter](https://docs.didit.me/es/authentication/quickstarts/flutter.md) > > 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](#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](https://docs.didit.me/es/authentication/sign-in-methods.md) 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. | Aplicación | Qué puedes registrar | | - | - | | Producción | URL `https://` | | Sandbox | URL `https://` y URL `http://` en `localhost`, `127.0.0.1` o `[::1]` | 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://.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`. | Configuración | Valores | Valor predeterminado | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` segundos | `2592000` (30 días) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` segundos | `86400` (1 día) | | `multiple_sessions` | `false` cierra las demás sesiones de la persona en cada nuevo inicio de sesión | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Finaliza todas las sesiones tras restablecer la contraseña | `true` | | `signup_policy` | `anyone`, `invited`, `allowed_domains` (con `allowed_email_domains`, hasta 100) | `anyone` | | `allow_subaddresses` | Acepta un `+` en la parte local del correo electrónico | `false` | | `post_logout_redirect_uri` | Adónde envía tu aplicación a la persona tras cerrar sesión | Vacío | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` o `own` | `hosted` | ## Mantener una misma persona en todos los productos Cada identidad tiene un valor `vendor_data`. Es el `external_id` que proporcionaste al [importar](https://docs.didit.me/es/authentication/migration.md) 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](https://docs.didit.me/es/authentication/events-and-webhooks.md). Obtén `vendor_data` en tu backend a partir de un token verificado, nunca de un campo del navegador sin comprobar. | Combinación de productos | Qué construyes | | - | - | | Autenticación | Inicio de sesión, validación de sesiones y cierre de sesión. | | Verificación de identidad + Autenticación | Inicia una verificación tras el inicio de sesión cuando tu política lo exija, con el `vendor_data` del token. | | Monitorización de transacciones + Autenticación | Envía transacciones para el `vendor_data` de la persona que ha iniciado sesión. Los eventos de inicio de sesión llegan a la cronología y a las reglas de esa misma persona. | | Los tres | Un único `vendor_data` por persona. Gestiona por separado la decisión de cada producto. | Usa el [prompt de integración compartido](https://docs.didit.me/es/integration/integration-prompt.md) para cualquier combinación. Lee [protección contra bots](https://docs.didit.me/es/authentication/bot-protection.md) para conocer las políticas que se aplican al iniciar sesión. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.