Guía de pruebas de gestores de contraseñas para claves de acceso en aplicaciones nativas

1. Introducción: Las claves de acceso en aplicaciones nativas y los gestores de contraseñas de terceros#

Con el lanzamiento de iOS 17 y Android 14, el panorama de las claves de acceso para aplicaciones móviles nativas ha cambiado fundamentalmente. Por primera vez, los gestores de contraseñas de terceros pueden actuar como proveedores de claves de acceso, rompiendo el monopolio exclusivo de iCloud Keychain y Google Password Manager. Esto permite a los usuarios utilizar sus propias soluciones de confianza como 1Password, Bitwarden o Dashlane en los flujos de autenticación de aplicaciones nativas. Si bien esto supone una gran victoria para la capacidad de elección del usuario, introduce una complejidad significativa para los desarrolladores. La implementación de sus claves de acceso puede comportarse de manera diferente según el gestor de contraseñas en las aplicaciones móviles nativas. Por lo tanto, es importante que cualquier equipo pruebe adecuadamente las claves de acceso en aplicaciones nativas y los gestores de contraseñas de terceros.

Esta guía completa comparte nuestro enfoque probado en batalla para realizar pruebas de claves de acceso en aplicaciones nativas con gestores de contraseñas de terceros. Aunque el ecosistema de las claves de acceso ha madurado significativamente en 2025, la implementación en el mundo real todavía requiere una validación cuidadosa a través de diversas implementaciones de gestores de contraseñas. Hemos resumido nuestra experiencia en un plan de pruebas práctico que asegura que su aplicación nativa funcione sin problemas con los gestores de contraseñas preferidos por los usuarios.

2. Por qué son importantes las pruebas de claves de acceso en producción#

2.1 Los usuarios traen su propio gestor de contraseñas#

El ecosistema de gestores de contraseñas ha evolucionado más allá de las soluciones nativas de la plataforma. Los usuarios eligen activamente gestores de contraseñas de terceros como 1Password, Bitwarden, Dashlane, Proton Pass y NordPass según sus necesidades específicas, como la sincronización multiplataforma, funciones empresariales o preferencias de privacidad. Su aplicación nativa para iOS/Android debe adaptarse a esta diversidad sin obligar a los usuarios a cambiar su solución de gestión de contraseñas de confianza.

Según los datos que medimos en las páginas de Corbado, vemos que solo entre el 5 y el 10 % de los usuarios generales dependen de gestores de contraseñas de terceros. Aunque este número pueda parecer bajo, tendrá un gran impacto en la percepción de su implementación de claves de acceso y en el número de tickets de soporte si trabaja en un entorno a gran escala. Hemos visto que algunos gestores de contraseñas implementan la especificación WebAuthn de manera ligeramente diferente, lo que provoca variaciones sutiles en la experiencia del usuario o incluso errores.

2.2 Diferentes patrones de experiencia de usuario en aplicaciones nativas#

Las aplicaciones nativas de iOS y Android ofrecen diferentes formas de usar las claves de acceso. En Android, encontrará superposiciones (overlays) de claves de acceso y entradas manuales en campos de texto que desencadenan una ceremonia de clave de acceso (para aplicaciones web, Android también es compatible con Conditional UI). iOS presenta su propio conjunto de superposiciones de claves de acceso junto con Conditional UI y también entradas manuales en campos de texto. Además, hay otros casos límite que se deben comprobar. En resumen, su aplicación nativa debe manejar de manera elegante:

• Inicios de sesión con superposición de claves de acceso que aparecen inmediatamente al cargar la página
• Inicios de sesión con Conditional UI (solo en iOS) que sugieren automáticamente las claves de acceso disponibles
• Inicios de sesión en campos de texto donde el usuario proporciona su nombre de usuario antes de hacer clic en un botón
• Autenticación entre dispositivos (CDA) para el uso de claves de acceso con otro dispositivo
• Mecanismos de respaldo (fallback) cuando el uso de claves de acceso no está disponible

2.3 Las marcas de WebAuthn requieren precisión#

La configuración correcta de las marcas (flags) determina si las claves de acceso funcionan como se espera en todos los dispositivos y plataformas. Los valores críticos incluyen:

• ID de la parte de confianza (Relying Party ID o rpID): Debe coincidir exactamente entre las implementaciones web y nativas y es el dominio al que está vinculada la clave de acceso.
• Verificación del usuario: Determina que el usuario debe proporcionar su autenticación local.
• Clave residente/credenciales descubribles: Permite la autenticación sin nombre de usuario (facilita la Conditional UI).
• Elegibilidad de copia de seguridad (BE) y estado de copia de seguridad (BS): Permite la sincronización de las claves de acceso entre dispositivos.

Las marcas mal configuradas no siempre causan fallos inmediatos. Sin embargo, podrían crear problemas sutiles e inconsistencias, como que las claves de acceso estén disponibles en un dispositivo pero no se sincronicen en otros (incluso si el mismo gestor de contraseñas de terceros está disponible en ambos dispositivos). Uno de nuestros hallazgos en las pruebas fue que algunos gestores de contraseñas de terceros configuran incorrectamente las marcas BE/BS, lo que representaba una gran fracción de los problemas de claves de acceso.

2.4 Gestión del ciclo de vida en aplicaciones de instancia única#

Las arquitecturas de actividad única (Android) y escena única (iOS) requieren una gestión meticulosa del ciclo de vida. Cuando aparece y se descarta una hoja del gestor de contraseñas, su aplicación debe preservar el estado, gestionar las devoluciones de llamada (callbacks) y reanudarse correctamente. Esto es especialmente crítico en Android, donde la configuración launchMode puede causar un comportamiento inesperado.

Por ejemplo, descubrimos que configurar MainActivity en launchMode="singleInstance" creaba problemas. En algunas versiones de Android y personalizaciones OEM, este modo provoca que la interfaz de usuario del Gestor de credenciales de claves de acceso se abra como una tarea separada. Esto no solo añade una entrada de aplicación adicional y confusa a la pantalla de "Recientes", sino que también puede hacer que la aplicación se congele si pasa a segundo plano mientras el cuadro de diálogo de la clave de acceso está abierto.

La solución recomendada es cambiar la configuración a launchMode="singleTask". Esto evita que el Gestor de credenciales genere una tarea separada, asegurando un ciclo de vida más predecible en diferentes OEM (Samsung, Google, Vivo, etc.) y reduciendo el riesgo de errores específicos del proveedor. Proporciona una base más estable para probar la navegación, las superposiciones y los enlaces profundos (deeplinks).

Hemos observado que tales problemas de ciclo de vida a menudo se disfrazan de "errores del gestor de contraseñas" cuando en realidad son problemas a nivel de la aplicación. Una instrumentación y pruebas adecuadas a través de diferentes proveedores ayuda a identificar estos patrones de manera temprana.

3. Configuración de su entorno de pruebas#

3.1 Gestores de contraseñas objetivo#

Enfoque las pruebas de claves de acceso de su aplicación nativa en los gestores de contraseñas de terceros más adoptados:

Objetivos principales (cobertura esencial):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Objetivos secundarios (basados en su base de usuarios):

• Proveedores regionales (por ejemplo, Samsung Pass para dispositivos Samsung)
• Soluciones empresariales si se dirige a usuarios de negocios
• Opciones predeterminadas de la plataforma (Google Password Manager, iCloud Keychain) como línea base

Evite la tentación de probar todos los gestores de contraseñas disponibles. Céntrese en los proveedores que representan el 90 % de su base de usuarios. Nuestros análisis mostraron que los cinco objetivos principales cubrían el 85 % de los usuarios de gestores de contraseñas de terceros en los mercados de UE/EE. UU./Reino Unido/AUS/NZ.

3.2 Lista de verificación previa#

Antes de iniciar cada ejecución de pruebas, asegúrese de tener un entorno limpio y reproducible:

1. Estado de credenciales limpio:

• Elimine todas las credenciales existentes para su ID de RP
• Borre las cachés del navegador y de la aplicación
• Cierre la sesión por completo y vuelva a iniciarla en el gestor de contraseñas
• Fuerce el cierre y vuelva a iniciar la aplicación objetivo

2. Estabilice el entorno de pruebas:

• Asegure una conectividad de red estable (sin VPN durante las pruebas)
• Desactive las animaciones de la interfaz de usuario si automatiza las pruebas
• Utilice una orientación de dispositivo consistente
• Documente la versión del sistema operativo, la versión de la aplicación y la versión del gestor de contraseñas

4. El plan de pruebas completo#

Cada prueba valida aspectos específicos de la funcionalidad de la clave de acceso. Documente los resultados sistemáticamente utilizando el estado de aprobado/fallido y notas detalladas para cualquier anomalía.

4.1 Pruebas del flujo de autenticación central#

Prueba 1: Abortar la creación de la clave de acceso (después de un inicio de sesión convencional exitoso)#

Validar el manejo de la cancelación elegante

✓ La hoja del gestor de contraseñas se abre correctamente
✓ El usuario cancela sin crear una clave de acceso
✓ La aplicación vuelve a la pantalla de inicio de sesión ✓ No hay credenciales huérfanas en el gestor de contraseñas
✓ La interfaz de usuario muestra las opciones de reintento adecuadas

Prueba 2: Crear una clave de acceso (después de un inicio de sesión convencional exitoso)#

Verificar la creación de la clave de acceso después del flujo de autenticación

✓ La autenticación local se inicia de forma fiable
✓ La autenticación biométrica se completa con éxito
✓ Credencial creada con el ID de RP correcto
✓ La aplicación transita al estado autenticado sin bucles

Prueba 3: Autenticarse con una clave de acceso existente#

Probar escenarios de autenticación estándar

✓ Aparece la interfaz de usuario de superposición de clave de acceso o el usuario proporciona el nombre de usuario en un escenario de campo de texto ✓ El escaneo biométrico y un único indicador biométrico conducen a una autenticación exitosa
✓ No hay bucles de selección ni reapariciones de la hoja
✓ La sesión se mantiene estable después de la autenticación

Prueba 4: Crear una clave de acceso desde Configuración#

Validar la gestión de claves de acceso dentro de la aplicación

✓ ID de RP correcto, descubribilidad y marcas BE/BS
✓ La aplicación permanece autenticada después de la creación
✓ El gestor de contraseñas se actualiza inmediatamente con las etiquetas correctas

Prueba 5: Eliminar la clave de acceso e intentar iniciar sesión de nuevo#

Probar la gestión del ciclo de vida de las credenciales

✓ Eliminar la clave de acceso en la configuración ✓ El inicio de sesión con clave de acceso no es posible
✓ Se ofrece una opción de respaldo (fallback) adecuada

4.2 Pruebas de compatibilidad multiplataforma#

Prueba 6: Usar una clave de acceso creada de forma nativa en la web (mismo dispositivo)#

Validar la portabilidad de aplicación a web

✓ El navegador reconoce las claves de acceso creadas por la aplicación
✓ La hoja de selección muestra la asociación RP correcta
✓ La autenticación se completa sin desvíos de código QR/CDA

Prueba 7: Usar una clave de acceso creada en la web en una aplicación nativa#

Probar el uso compartido de credenciales de web a aplicación

✓ La aplicación muestra la credencial creada en la web en la selección
✓ La autenticación en el primer intento tiene éxito
✓ Sin respaldo de contraseña forzado

Prueba 8: Sincronización entre dispositivos (de móvil a escritorio)#

Verificar la sincronización de la clave de acceso de la aplicación nativa al navegador de escritorio

✓ La clave de acceso creada en la aplicación se sincroniza con el gestor de contraseñas de escritorio ✓ La clave de acceso sincronizada funciona sin problemas en el navegador de escritorio ✓ No se activa ningún código QR / flujo entre dispositivos ✓ La autenticación se completa sin bucles ni errores

Prueba 9: Sincronización entre dispositivos (de escritorio a móvil)#

Verificar la sincronización de la clave de acceso del navegador de escritorio a la aplicación nativa

✓ La clave de acceso creada en el escritorio se sincroniza con el gestor de contraseñas móvil ✓ La aplicación nativa muestra correctamente la clave de acceso sincronizada ✓ La autenticación tiene éxito sin respaldo de contraseña ✓ Los registros vinculan la afirmación (assertion) con el ID de credencial correcto

Prueba 10: Móvil como autenticador para la web#

Validar los escenarios de teléfono como llave de seguridad

✓ El teléfono ofrece credenciales creadas en la aplicación para CDA web
✓ No hay errores falsos de "no hay claves de acceso disponibles"
✓ La sesión web se completa después de la biometría móvil

5. Problemas comunes y estrategias de mitigación#

Nuestras extensas pruebas revelaron varios patrones recurrentes que afectan la integración de las claves de acceso en gestores de contraseñas de terceros:

Retrasos en la sincronización entre dispositivos#

Problema: Las credenciales creadas en un dispositivo pueden no aparecer inmediatamente en otros.

Solución: Implemente una lógica de reintento con retroceso exponencial. Proporcione opciones de actualización manual para los usuarios que experimentan retrasos en la sincronización.

Comportamientos específicos de la versión#

Problema: El comportamiento del gestor de contraseñas varía significativamente entre las versiones del sistema operativo, especialmente en Android 14+ e iOS 17+.

Solución: Mantenga una matriz de compatibilidad y ajuste los flujos según la versión del sistema operativo detectada. Considere los requisitos mínimos de versión para una experiencia óptima.

6. Conclusión: Construyendo soporte de claves de acceso listo para producción#

Implementar con éxito el soporte de claves de acceso de gestores de contraseñas de terceros en aplicaciones nativas requiere pruebas metódicas y atención al detalle. Nuestro plan de pruebas completo, perfeccionado a través de pruebas en el mundo real, proporciona una base sólida para validar su integración de claves de acceso.

Puntos clave para el despliegue en producción:

1. Pruebe sistemáticamente: Utilice nuestro plan de pruebas como base, adaptándolo a sus casos de uso específicos.
2. Respete la elección del usuario: Respalde los gestores de contraseñas que prefieren sus usuarios, no solo los predeterminados de la plataforma.
3. Monitoree continuamente: Implemente un registro (logging) completo para detectar casos límite en producción.
4. Documente minuciosamente: Mantenga registros claros de los comportamientos específicos de los proveedores y las soluciones temporales (workarounds).

El ecosistema de las claves de acceso continúa evolucionando rápidamente. Los gestores de contraseñas actualizan regularmente sus implementaciones, los sistemas operativos introducen nuevas funciones y la propia especificación WebAuthn avanza. Al establecer un marco de pruebas sólido ahora, estará preparado para adaptarse a medida que la tecnología madure.

Continuaremos actualizando nuestros SDK y nuestra metodología de pruebas a medida que surjan nuevos patrones. La inversión en pruebas exhaustivas de gestores de contraseñas de terceros rinde frutos al reducir la carga de soporte y mejorar la satisfacción del usuario. Después de todo, la autenticación simplemente debería funcionar, independientemente del gestor de contraseñas que elijan sus usuarios.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

Preguntas frecuentes#

¿Qué gestores de contraseñas de terceros debo priorizar al probar claves de acceso en aplicaciones nativas?#

Priorice 1Password, Bitwarden, Dashlane, Proton Pass y NordPass como objetivos principales. Estos cinco proveedores cubren el 85 % de los usuarios de gestores de contraseñas de terceros en los mercados de la UE/EE. UU./Reino Unido/AUS/NZ, lo que proporciona una amplia cobertura sin invertir en exceso en proveedores minoritarios.

¿Por qué las claves de acceso creadas en una aplicación nativa no se sincronizan entre dispositivos al usar un gestor de contraseñas de terceros?#

La configuración incorrecta de las marcas de elegibilidad de copia de seguridad (BE) y estado de copia de seguridad (BS) es una causa principal de los fallos de sincronización entre dispositivos. Algunos gestores de contraseñas de terceros configuran estas marcas incorrectamente, por lo que una clave de acceso existe en un dispositivo pero no se sincroniza con otros, incluso cuando el mismo gestor de contraseñas está instalado en ambos.

¿Cómo soluciono los errores de la interfaz de usuario de Credential Manager en Android que aparecen como tareas separadas en la pantalla de Recientes?#

Configurar MainActivity en launchMode singleInstance hace que la interfaz de usuario de Credential Manager se genere como una tarea separada, lo que crea una entrada confusa en Recientes y potencialmente bloquea la aplicación cuando pasa a segundo plano. Cambiar la configuración a launchMode singleTask resuelve esto en fabricantes de equipos originales, incluidos Samsung, Google y Vivo.

¿Qué flujos de autenticación debo probar al validar el soporte de un gestor de contraseñas de terceros en una aplicación nativa de iOS o Android?#

Un plan de pruebas completo cubre 10 escenarios: creación y cancelación elegante de claves de acceso, autenticación mediante superposición y campo de texto, gestión de credenciales dentro de la aplicación, eliminación de credenciales con mecanismo de respaldo (fallback) y sincronización bidireccional entre dispositivos. Las pruebas multiplataforma también deben confirmar que las claves de acceso creadas en la aplicación se autentican en un navegador y que las claves de acceso creadas en la web se autentican en la aplicación nativa.