Problemas del día 2 de las claves de acceso: 5 riesgos tras el lanzamiento

1. Introducción: Riesgos de las claves de acceso tras el lanzamiento#

No implementes claves de acceso.

Al menos no a cualquier precio y no si no tienes los recursos para hacerlo correctamente.

Sí, las claves de acceso son lo mejor que le ha pasado a la autenticación de consumidores en una década. Sí, acaban con el phishing. Sí, pueden mejorar enormemente la experiencia del usuario. Pero las claves de acceso mal implementadas también pueden causar mucho daño.

Implementar un servidor WebAuthn no es demasiado complejo. El verdadero desafío es todo lo que lo rodea. Operar claves de acceso de manera eficiente a gran escala requiere planificación anticipada. Debes pensar en todos los problemas del "día 2": las realidades operativas que solo surgen después de haber comenzado la implementación de las claves de acceso.

Este artículo cubre cinco problemas del día 2 que constantemente acaban con los proyectos de claves de acceso. Si no puedes resolverlos todos, no estás listo para implementar claves de acceso. Si puedes, crearás una autenticación que sea a la vez más segura y más utilizable que cualquier cosa que las contraseñas pudieran ofrecer.

2. ¿Qué son los problemas del día 2 de las claves de acceso?#

En ingeniería, el "día 1" es cuando construyes y lanzas. El "día 2" es cuando operas, mantienes y escalas lo que has lanzado. Para las claves de acceso, el día 1 puede ser sencillo:

• integra un servidor WebAuthn en tu pila empresarial
• añade los flujos del frontend y lánzalo.

La mayoría de los equipos pueden conseguir que una implementación básica de claves de acceso funcione en unos pocos días o semanas.

El día 2 es donde fracasan los proyectos. Es el momento en que los usuarios reales, en dispositivos reales, con casos extremos reales, interactúan con tu sistema de claves de acceso. Es cuando descubres que la brillante demostración que funcionaba perfectamente en tu MacBook se rompe en un portátil con Windows que ejecuta Chrome detrás de un proxy corporativo. Es cuando tu equipo de soporte se inunda de tickets del tipo "ya no puedo iniciar sesión".

La brecha entre una demostración funcional de claves de acceso y una implementación de claves de acceso a nivel de producción es enorme. Ya hemos cubierto antes los obstáculos de la implementación técnica y las razones estratégicas por las que fracasan los proyectos de claves de acceso. Este artículo se centra específicamente en lo que sucede después del lanzamiento desde una perspectiva operativa.

3. Problema 1: La recuperación y las alternativas son difíciles de asegurar#

Si no diseñas la recuperación y la alternativa correctamente, o bloqueas a los usuarios a gran escala o vuelves a introducir silenciosamente los mismos flujos propensos al phishing que querías eliminar.

3.1 Riesgo de bloqueo de cuenta a gran escala#

Imagina a un usuario que registra una clave de acceso en su iPhone y luego lo pierde. Por lo general, una gran parte de estos casos de recuperación ahora es manejada por el gestor de credenciales (muy probablemente el Llavero de iCloud en los iPhones). Mientras el usuario tenga acceso a su cuenta de Apple, tendrá claves de acceso sincronizadas disponibles para iniciar sesión en un nuevo dispositivo. Pero, ¿y si ya no tiene acceso a esa cuenta en la nube? Aquí es cuando entra en juego tu ruta de recuperación habitual.

Digamos que asumes que la clave privada todavía está disponible en el dispositivo desde el cual el usuario intenta iniciar sesión, por lo que inicias la ceremonia de inicio de sesión de WebAuthn. Esto dará como resultado un modal del SO / navegador que le pedirá al usuario que "inicie sesión con su clave de acceso en otro dispositivo". Básicamente, el usuario ahora está bloqueado de su cuenta. No hay ningún otro dispositivo donde esté almacenada la clave de acceso. El usuario está enormemente confundido. Multiplica esto por miles de usuarios y tendrás una crisis de soporte.

La reacción común es agregar restablecimientos de cuenta basados en correo electrónico como alternativa. Pero esto anula el propósito de las claves de acceso: acabas de reintroducir un canal de recuperación susceptible de phishing. Un atacante que pueda comprometer el correo electrónico de un usuario ahora puede eludir por completo tu implementación de claves de acceso resistente al phishing.

3.2 Diseñar alternativas sin reintroducir el phishing#

En nuestra opinión, el enfoque correcto es la recuperación por capas:

1. Claves de acceso sincronizadas como estrategia principal: asegúrate de que los usuarios creen claves de acceso sincronizadas (a través del Llavero de iCloud, el Gestor de contraseñas de Google o un proveedor de claves de acceso de terceros) para que la pérdida del dispositivo no signifique la pérdida de la credencial.
2. Autenticación multidispositivo como segunda capa: permite a los usuarios autenticarse desde otro dispositivo donde esté disponible otra clave de acceso escaneando un código QR.
3. Verificación de identidad (IDV) como tercera capa: ofrece IDV automatizada con controles de prueba de vida en lugar de recurrir a contraseñas/OTP.
4. Credenciales verificables digitales como cuarta capa: es la versión más segura, que preserva la privacidad y es más fácil de usar para la recuperación de cuentas. Esto permite al usuario utilizar sus credenciales verificables digitales (p. ej., un DNI digital o mDL) para verificar su identidad mediante API estándar (p. ej., Digital Credentials API). Esta tecnología es bastante nueva y la adopción no es alta, pero jugará un papel importante en los próximos meses y años.

En general, debes decidir qué capas de recuperación de cuenta se pueden justificar desde una perspectiva de coste/fricción. Por ejemplo, en el comercio minorista / comercio electrónico, podrías ofrecer solo las dos primeras capas y aceptar el riesgo de phishing por razones financieras. En otras industrias, donde la seguridad es más importante, pasas a la capa 3 y 4.

Cada capa añade complejidad. Debes decidir qué capas requiere tu caso de uso, construirlas, probarlas en todas las combinaciones de dispositivos y monitorear su uso. Esto es significativamente más trabajo que la integración inicial de WebAuthn.

3.3 En qué se equivocan la mayoría de los equipos#

La mayoría de los equipos simplifican en exceso la recuperación (recurriendo a contraseñas o SMS OTP) o la complican demasiado (p. ej., exigiendo llaves de seguridad de hardware para cada recuperación). El equilibrio correcto depende de tu modelo de amenazas, tu base de usuarios y los requisitos reglamentarios. Equivocarse significa socavar tu postura de seguridad o crear tanta fricción que los usuarios abandonen el flujo.

4. Problema 2: Los casos límite entre dispositivos y ecosistemas rompen los flujos de las claves de acceso#

Tus usuarios no viven en un mundo limpio y exclusivo de Apple. Cambian de dispositivo, mezclan Windows con iOS, usan diferentes navegadores y trabajan en configuraciones administradas por la empresa. Ahí es donde se rompen los flujos de las claves de acceso si no lo has previsto.

4.1 La fragmentación del ecosistema es real#

El ecosistema de las claves de acceso abarca tres plataformas principales (Apple, Google y Microsoft), múltiples navegadores (Chrome, Safari, Firefox y Edge), docenas de proveedores de claves de acceso / gestores de credenciales (p. ej., 1Password, Bitwarden, Dashlane y otros) e innumerables combinaciones de SO/navegador/dispositivo. Cada combinación puede comportarse de forma ligeramente diferente, por ejemplo:

• Apple sincroniza las claves de acceso por defecto a través del Llavero de iCloud en iOS, iPadOS y macOS, pero no en Windows o Android
• Google sincroniza a través del Gestor de contraseñas de Google en Android y Chrome, pero la experiencia en iOS es diferente (debes configurarlo manualmente)
• Windows tiene su propio comportamiento de claves de acceso que difiere significativamente de otras plataformas
• Los gestores de contraseñas manejan la creación y selección de claves de acceso de manera diferente, a veces en conflicto con los avisos nativos de la plataforma

4.2 Flujos de autenticación multidispositivo#

Cuando un usuario crea una clave de acceso en su iPhone pero quiere iniciar sesión en un portátil con Windows, puede usar la autenticación multidispositivo (normalmente a través de código QR y Bluetooth). Este flujo funciona pero es frágil:

• Requiere que el Bluetooth esté habilitado en ambos dispositivos
• Los cortafuegos corporativos y las políticas de MDM pueden interferir, ya que se establece un túnel en segundo plano
• La experiencia del usuario varía drásticamente entre navegadores
• A menudo, los usuarios no entienden qué está pasando o por qué están escaneando un código QR

Hemos visto estos casos límite de primera mano en miles de combinaciones de dispositivos. Si estás creando claves de acceso internamente, debes probar y gestionar cada una de ellas. Si no puedes, tus usuarios se encontrarán con errores que tu equipo de soporte no podrá explicar.

4.3 Inconsistencias entre navegadores y SO#

Incluso en el mismo dispositivo, los diferentes navegadores se comportan de manera distinta. Chrome en macOS muestra modales de claves de acceso diferentes a Safari en macOS. Firefox tiene su propio comportamiento. Los hints del cliente y la detección del user agent se vuelven críticos para ofrecer los flujos correctos al usuario adecuado, pero analizarlos correctamente en todas las combinaciones es una carga de mantenimiento que nunca termina.

5. Problema 3: Las aplicaciones nativas multiplican la complejidad de las claves de acceso#

Las pruebas y el control de calidad de las claves de acceso ya son un desafío para las aplicaciones web (lo cubrimos en detalle en el Problema 5: Los cambios de plataforma rompen las claves de acceso silenciosamente). Pero si tu producto también tiene aplicaciones nativas de iOS y Android, la complejidad se multiplica debido a las decisiones arquitectónicas y al comportamiento específico de la plataforma a las que los equipos centrados exclusivamente en la web nunca se enfrentan.

5.1 Decisiones: Nativo vs. WebView#

La primera decisión es si implementar claves de acceso de forma nativa o a través de un WebView. Cada enfoque tiene sus pros y contras:

Solo en iOS, puedes elegir entre WKWebView, SFSafariViewController, SFAuthenticationSession y ASWebAuthenticationSession, cada uno con diferentes características de soporte de claves de acceso. En Android, las Chrome Custom Tabs se comportan de forma diferente a los WebViews estándar. Estas son decisiones que los equipos que solo trabajan en la web nunca tienen que tomar y cada elección crea su propia superficie de mantenimiento.

5.2 Comportamiento específico de la plataforma en aplicaciones nativas#

Más allá de la decisión arquitectónica, iOS y Android manejan las claves de acceso de manera diferente a nivel del sistema operativo:

• iOS integra las claves de acceso profundamente en el gestor de credenciales del sistema, con comportamientos de autocompletado específicos que pueden cambiar con cada versión de iOS
• Android enruta las solicitudes de claves de acceso a través de la Credential Manager API, que interactúa con múltiples proveedores de claves de acceso simultáneamente
• Los estados de error, los comportamientos de tiempo de espera y las indicaciones al usuario difieren entre plataformas. Lo mismo que el usuario cancela se muestra como NotAllowedError en la web, pero como SimpleAuthenticationServices.AuthorizationError en iOS y User cancelled the operation en el Credential Manager de Android; consulta los errores de WebAuthn en producción para obtener un mapeo de errores completo multiplataforma
• Los ciclos de revisión de las tiendas de aplicaciones añaden retrasos cuando necesitas implementar correcciones urgentes para regresiones de las claves de acceso

5.3 Superficie de control de calidad triplicada#

Si operas tanto una aplicación web como aplicaciones nativas, no solo estás duplicando el esfuerzo de control de calidad, sino que lo estás triplicando. Web, iOS y Android se comportan como entornos de claves de acceso separados que necesitan pruebas de extremo a extremo y monitorización independientes. Y a diferencia de la web, donde puedes implementar una solución al instante, las correcciones de las aplicaciones nativas están limitadas por los ciclos de revisión de las tiendas de aplicaciones.

6. Problema 4: La adopción es un problema de producto, no un problema técnico#

"Se admiten claves de acceso" no significa "se utilizan claves de acceso". Si no tienes una estrategia de implementación y medición, tu adopción decepcionará y el proyecto será etiquetado internamente como un fracaso.

6.1 Por qué la baja adopción acaba con tu proyecto#

Hemos cubierto esto extensamente en nuestro artículo sobre por qué fracasan las implementaciones de claves de acceso: si los usuarios no cambian a las claves de acceso, el proyecto ya ha fracasado. Las contraseñas siguen siendo dominantes, los costes de SMS OTP siguen siendo altos, los riesgos de phishing persisten y tu organización no ve retorno en una inversión significativa en ingeniería.

El caso de negocio para la adopción de claves de acceso es sólido, pero solo si la adopción realmente ocurre. Hemos visto empresas lanzar claves de acceso con grandes implementaciones técnicas que lograron menos del 5 % de adopción porque nadie pensó en la estrategia de implementación y adopción.

6.2 La adopción requiere trabajo deliberado de producto#

Impulsar la adopción de las claves de acceso es un desafío de producto que requiere:

• Inscripción progresiva: animar a los usuarios a crear claves de acceso en los momentos adecuados (p. ej., después de un inicio de sesión exitoso, durante las revisiones de seguridad de la cuenta)
• Comunicación clara al usuario: explicar qué son las claves de acceso y por qué son mejores, en un lenguaje que los usuarios no técnicos entiendan
• Solicitudes conscientes del dispositivo: ofrecer la creación de claves de acceso solo cuando el dispositivo del usuario realmente las soporte bien, evitando experiencias frustrantes en configuraciones no compatibles
• Infraestructura de medición: rastrear las tasas de creación de claves de acceso, las tasas de éxito de inicio de sesión, las tasas de alternativas y las tasas de abandono para identificar y solucionar cuellos de botella

6.3 Cómo es una "buena" adopción#

Según nuestra experiencia con implementaciones de claves de acceso a gran escala, esto es a lo que deberían aspirar las empresas:

Si tus cifras de adopción se parecen a la columna "débil" después de tres meses, el proyecto está en problemas. Sin analíticas para medir esto, ni siquiera lo sabrás.

7. Problema 5: Los cambios de plataforma rompen las claves de acceso silenciosamente#

Las actualizaciones del sistema operativo y del navegador cambian los avisos, el comportamiento de autocompletado y los flujos alternativos. Si no tienes una monitorización continua, obtendrás regresiones y tickets de soporte sin previo aviso.

Acabamos de publicar una descripción general completa de los errores de WebAuthn que ocurrieron en producción.

7.1 Por qué las claves de acceso se ven singularmente afectadas por los cambios de plataforma#

A diferencia de las contraseñas (que son solo cadenas que tu servidor valida), las claves de acceso dependen de una profunda integración con el sistema operativo, el navegador y el gestor de credenciales. Cuando Apple lanza una nueva versión de iOS, los avisos de creación de claves de acceso pueden tener un aspecto diferente. Cuando Chrome actualiza su lógica de autocompletado, tu flujo de inicio de sesión podría romperse. Cuando un gestor de contraseñas lanza una nueva versión, podría comenzar a interceptar las solicitudes de claves de acceso de formas que no habías anticipado.

Un ejemplo reciente es el error de iOS 26.2 donde isUserVerifyingPlatformAuthenticatorAvailable() devuelve false en todos los navegadores que no son Safari (Chrome, Edge, Firefox), lo que requiere una lógica de detección consciente de la plataforma utilizando getClientCapabilities() como solución alternativa.

7.2 La monitorización no es opcional#

Para asegurarte de estar al tanto de todos los posibles errores y rastrear la adopción, debes configurar tu pila de observabilidad de autenticación. Recomendamos tener al menos lo siguiente en marcha:

• Analítica de autenticación en tiempo real: rastrea las tasas de éxito y fracaso por combinación de sistema operativo, navegador y proveedor de claves de acceso
• Monitorización consciente de la versión: detecta cuándo una nueva versión del sistema operativo o navegador provoca un aumento en los errores o alternativas. Distingue entre errores esperados (los abortos del usuario se muestran como NotAllowedError) y errores inesperados (picos de AbortError por errores de concurrencia o nuevos errores de claves de acceso del Credential Manager después de una actualización de Android)
• Alertas: recibe notificaciones antes de que tus usuarios comiencen a presentar tickets de soporte
• Capacidad de respuesta rápida: la capacidad de aplicar soluciones rápidas o deshabilitar las claves de acceso para las combinaciones de dispositivos afectadas de forma rápida

Este es el tipo de infraestructura de analítica de autenticación que la mayoría de los equipos no construyen hasta que ya han tenido un incidente. Para entonces, el daño a la confianza del usuario y a la credibilidad del proyecto interno ya está hecho.

7.3 Coste de mantenimiento continuo#

El verdadero coste de la implementación de claves de acceso no es la compilación inicial. Es el mantenimiento continuo:

• Monitorizar los cambios de plataforma en iOS, Android, Windows, macOS y todos los navegadores principales
• Probar cada actualización en busca de regresiones
• Actualizar tu SDK de frontend cuando cambian las API del navegador
• Mantener la compatibilidad con un ecosistema creciente de proveedores de claves de acceso
• Documentar y comunicar los cambios a tu equipo de soporte

8. Cuándo deberías (o no) implementar claves de acceso#

Teniendo en cuenta estos problemas del día 2, aquí tienes una evaluación honesta de cuándo deberías y no deberías implementar claves de acceso.

8.1 No implementes claves de acceso si#

• No tienes una estrategia clara de alternativas y recuperación
• No has probado las combinaciones de dispositivos que realmente usan tus usuarios
• Tienes aplicaciones nativas pero no tienes un plan para el control de calidad continuo específico de la plataforma
• No tienes infraestructura analítica para medir la adopción
• No puedes comprometer recursos de ingeniería para el mantenimiento continuo
• Estás implementando claves de acceso puramente para cumplir con una casilla de verificación de cumplimiento sin una planificación adecuada

Ir a por todas por razones regulatorias sin una planificación adecuada puede aumentar los costes significativamente. Un sistema de claves de acceso mal implementado es peor que no tener ningún sistema: erosiona la confianza del usuario, genera gastos generales de soporte y da a las partes interesadas internas una razón para eliminar el proyecto.

8.2 Implementa claves de acceso si#

• Has planificado para los cinco problemas del día 2 descritos anteriormente
• Tienes las capacidades de producto, ingeniería, seguridad y analítica para respaldar una implementación continua
• Has presupuestado el mantenimiento continuo, no solo la compilación inicial
• Tienes una estrategia de implementación por fases con objetivos de adopción claros
• Estás trabajando con un socio como Corbado que maneja la complejidad operativa por ti

8.3 Decisión de construir vs. comprar#

Los problemas del día 2 descritos en este artículo son exactamente la razón por la que muchas empresas eligen comprar en lugar de construir su infraestructura de claves de acceso. Construir un servidor WebAuthn es la parte fácil. Operar un sistema de claves de acceso a nivel de producción en miles de combinaciones de dispositivos, con recuperación, monitorización y analíticas de adopción adecuadas, es lo que separa una demostración de una implementación real.

9. Cómo resuelve Corbado los problemas del día 2 de las claves de acceso#

Corbado existe específicamente porque los problemas del día 2 son difíciles. Nuestra plataforma maneja la complejidad operativa para que no tengas que construirla y mantenerla tú mismo.

9.1 Recuperación y alternativas#

Corbado proporciona flujos de recuperación listos para usar con niveles de seguridad adaptables. Desde estrategias de claves de acceso sincronizadas hasta autenticación multidispositivo o verificación de identidad automatizada. La lógica de recuperación está integrada y se actualiza continuamente.

9.2 Compatibilidad multidispositivo#

Nuestros SDK de frontend están preprobados en miles de combinaciones de sistemas operativos, navegadores y proveedores de claves de acceso. La detección de dispositivos, la gestión de la IU condicional y el enrutamiento alternativo se realizan de forma automática. Cuando una nueva versión del navegador rompe algo, lo arreglamos en nuestro SDK antes de que tus usuarios se den cuenta.

9.3 Soporte de aplicaciones nativas#

Corbado soporta implementaciones de claves de acceso tanto nativas como WebView con SDK que abstraen las diferencias de plataforma. Tú te enfocas en la UX de tu aplicación mientras nosotros manejamos la plomería de las claves de acceso en iOS y Android.

9.4 Analíticas de adopción#

Nuestro panel de analíticas rastrea cada métrica que importa: tasas de creación de claves de acceso, tasas de éxito de inicio de sesión, tasas de alternativas y desgloses a nivel de dispositivo. Obtienes información procesable para impulsar la adopción, no solo datos sin procesar.

9.5 Monitorización de cambios de plataforma#

Corbado monitoriza continuamente los cambios de SO y navegador que afectan a las claves de acceso. Nuestros SDK se actualizan de forma proactiva. Tu implementación de claves de acceso se mantiene estable incluso a medida que cambia el panorama de la plataforma.

10. Conclusión#

Las claves de acceso son el estándar de oro de la autenticación. Eso no se cuestiona. Pero el camino de "se admiten claves de acceso" a "las claves de acceso funcionan de manera fiable a gran escala" está pavimentado con problemas del día 2 que la mayoría de los equipos subestiman.

Los cinco problemas que hemos cubierto (recuperación, casos límite multidispositivo, complejidad de aplicaciones nativas, adopción y cambios de plataforma) no son raros. Son los desafíos operativos centrales de cualquier implementación de claves de acceso de producción. Ignorarlos no hace que desaparezcan. Solo significa que tus usuarios los descubrirán primero.

Mi recomendación honesta: si no tienes los conocimientos y los recursos para hacer las claves de acceso correctamente, no las implementes. Invierte en las capacidades (producto, ingeniería, seguridad y analíticas) o trabaja con un socio que ya haya resuelto estos problemas. El peor resultado es una implementación de claves de acceso a medias que se revierte porque nadie planificó el día 2.

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#

¿Cuáles son los 5 problemas del día 2 que provocan que los proyectos de claves de acceso fracasen tras el lanzamiento?#

Los cinco problemas operativos son flujos alternativos y de recuperación inseguros, casos límite del ecosistema multidispositivo, la complejidad de las aplicaciones nativas, la baja adopción por parte de los usuarios y las regresiones silenciosas derivadas de las actualizaciones del SO y los navegadores. La mayoría de los equipos se centran en la integración inicial de WebAuthn y subestiman estos desafíos posteriores al lanzamiento, por lo que muchos proyectos de claves de acceso se revierten o se abandonan silenciosamente a nivel interno.

¿Cómo gestiono la autenticación de claves de acceso multidispositivo para usuarios empresariales en Windows que se registraron en un iPhone?#

Los usuarios pueden autenticarse a través de un código QR y un flujo multidispositivo Bluetooth, pero esto requiere que el Bluetooth esté habilitado en ambos dispositivos y puede ser bloqueado por políticas corporativas de MDM y cortafuegos. La experiencia del usuario varía significativamente entre navegadores y los usuarios a menudo no entienden por qué están escaneando un código QR, lo que hace que el enrutamiento alternativo consciente del dispositivo y una comunicación clara sean fundamentales para las implementaciones empresariales.

¿Qué métricas de adopción de claves de acceso debería marcarme como objetivo y rastrear después del lanzamiento?#

Una adopción sólida significa una tasa de creación de claves de acceso superior al 60 % de los usuarios elegibles y una tasa de inicio de sesión con claves de acceso superior al 40 % de todos los inicios de sesión. Las tasas inferiores al 10 % en creación y al 5 % en inicio de sesión después de tres meses indican una implementación fallida. Medir esto requiere una infraestructura dedicada que realice un seguimiento de las tasas de creación, las tasas de éxito de inicio de sesión, las tasas de alternativas y el abandono desglosado por combinación de dispositivo y SO.

¿Debería compilar claves de acceso de forma nativa en mi aplicación móvil o usar un WebView?#

La implementación nativa ofrece la mejor experiencia de usuario de su clase, pero requiere bases de código independientes para iOS y Android con gestión de API específica de la plataforma y canales de control de calidad (QA) independientes. Los enfoques de WebView comparten la lógica web pero introducen inconsistencias en el soporte de las claves de acceso según el tipo de WebView. Solo en iOS, la elección entre WKWebView, SFSafariViewController y ASWebAuthenticationSession conlleva diferentes características de soporte de claves de acceso que deben evaluarse antes de comprometerse con una arquitectura.

¿Por qué la recuperación de cuentas con claves de acceso es más difícil de lo que parece y cuál es el enfoque correcto?#

Una recuperación simplificada, como los restablecimientos basados en correo electrónico, reintroduce canales propensos al phishing, mientras que una recuperación demasiado estricta, como las llaves de seguridad de hardware obligatorias, genera abandono. El enfoque recomendado es por capas: claves de acceso sincronizadas como estrategia principal, autenticación de código QR multidispositivo como segunda capa, verificación de identidad automatizada con controles de vida como tercera y credenciales verificables digitales como cuarta. Las capas que debes implementar dependen de tu modelo de amenazas, tu base de usuarios y los requisitos normativos.