Passkeys en aplicaciones nativas: Implementación nativa frente a WebView

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Nota: System WebView y Embedded WebView a menudo se combinan, donde System WebView gestiona el inicio de sesión (con credenciales compartidas automáticamente) y luego Embedded WebView renderiza la gestión de passkeys en los ajustes.

Factores clave de decisión:

• ¿Inicio de sesión basado en OAuth? → System WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• ¿Quieres reutilizar la autenticación web en una carcasa nativa? → Embedded WebView (WKWebView, WebView de Android con WebKit 1.12.1+)
• ¿Estás creando una aplicación principalmente nativa? → Implementación nativa (AuthenticationServices de Apple, Credential Manager de Google)

Las plataformas móviles modernas ofrecen tres enfoques distintos para integrar passkeys en tu aplicación nativa, cada uno con diferentes ventajas y desventajas en cuanto a experiencia de usuario, complejidad técnica y compatibilidad con OAuth:

1. Implementación nativa: Construye los flujos de passkeys directamente en tu aplicación usando las API de la plataforma (AuthenticationServices en iOS, Credential Manager en Android). Proporciona la mejor experiencia de usuario con una autenticación biométrica fluida, pero requiere un esfuerzo de implementación técnica de medio a alto.

2. System WebView: Usa el componente de navegador de la plataforma (ASWebAuthenticationSession / SFSafariViewController en iOS, Chrome Custom Tabs en Android) para gestionar la autenticación. Es excelente para flujos de inicio de sesión basados en OAuth y comparte credenciales con el navegador del sistema.

3. Embedded WebView: Incrusta una vista web personalizable (WKWebView en iOS, WebView en Android) dentro de tu aplicación para reutilizar la autenticación web con un esqueleto de aplicación nativa. Proporciona una apariencia similar a la nativa sin barras de URL y control total sobre la UI de la vista web. Requiere configuración adicional, incluyendo permisos y entitlements (iOS), y configuración de WebView con AndroidX WebKit 1.12.1+ (Android) para habilitar la funcionalidad de passkeys.

La elección correcta depende de la arquitectura de autenticación de tu aplicación, si usas proveedores OAuth, cuánto control necesitas sobre la interfaz de usuario y si estás construyendo una aplicación principalmente nativa o reutilizando componentes web.

Una implementación nativa de passkeys proporciona la experiencia de usuario óptima, con flujos de autenticación construidos directamente en la interfaz de usuario de tu aplicación mediante API específicas de la plataforma. Los usuarios se benefician de diálogos nativos de la plataforma, verificación biométrica fluida y los tiempos de inicio de sesión más rápidos posibles.

Cuándo elegir la implementación nativa:

• Al construir una nueva aplicación nativa o refactorizar la autenticación a pantallas nativas
• Si se busca la mejor experiencia de usuario posible con autenticación instantánea y silenciosa
• Sugerencias automáticas de passkeys al iniciar la aplicación: Las implementaciones nativas pueden usar preferImmediatelyAvailableCredentials para mostrar automáticamente una superposición de passkeys cuando hay passkeys disponibles, proporcionando la experiencia de inicio de sesión más rápida sin necesidad de introducir un identificador
• Si se necesita control total sobre la interfaz de usuario y el flujo de autenticación
• Si se está dispuesto a invertir en una implementación específica para cada plataforma (Swift en iOS, Kotlin en Android)

Ventaja clave: preferImmediatelyAvailableCredentials()

Las implementaciones nativas pueden aprovechar preferImmediatelyAvailableCredentials() para crear una superposición automática de passkeys que aparece inmediatamente al iniciar la aplicación cuando hay passkeys disponibles. Este flujo sin nombre de usuario proporciona la experiencia de inicio de sesión más rápida posible: los usuarios ven sus passkeys al instante sin tener que introducir primero un identificador. Esta capacidad es exclusiva de las implementaciones nativas y no está disponible en las variantes de WebView.

Aunque las implementaciones de WebView pueden usar Conditional UI (sugerencias de passkeys en los campos de entrada), la superposición automática de las implementaciones nativas proporciona una UX superior con tasas de uso de passkeys más altas, ya que la autenticación comienza inmediatamente al lanzar la aplicación.

Resumen de requisitos técnicos:

La integración nativa de passkeys requiere una confianza criptográfica entre tu aplicación y tu dominio web. Sin ella, el sistema operativo rechazará todas las operaciones de WebAuthn. Requisitos clave:

1. Archivos de asociación de dominio de la aplicación alojados en /.well-known/
2. Relying Party ID correcto que coincida con tu dominio web
3. Capacidades específicas de la plataforma (detalladas en la Sección 4)

El principal beneficio: los passkeys creados en tu sitio web funcionan perfectamente en tu aplicación y viceversa.

Implementar passkeys de forma nativa en iOS implica el uso del framework AuthenticationServices de Apple, que proporciona una API para operaciones WebAuthn:

Componentes clave:

• ASAuthorizationController: Gestiona el flujo de autenticación
• ASAuthorizationPlatformPublicKeyCredentialProvider: Crea solicitudes de passkeys
• Tres modos de interfaz de usuario distintos para gestionar los inicios de sesión con passkeys:
  • Inicio de sesión en campo de texto: Campo de nombre de usuario tradicional con el inicio de sesión con passkey que comienza al pulsar un botón
  • Superposición modal de passkey: Diálogo del sistema operativo que lista los passkeys disponibles
  • Conditional UI: Sugerencias de passkeys en la barra QuickType sobre el teclado

Consejos de desarrollo

• Caché de AASA: Apple almacena en caché el archivo AASA de forma agresiva (hasta 24 horas), lo que puede frustrar las pruebas. Solución: Habilita el Modo Desarrollador en tu dispositivo de prueba y añade ?mode=developer a la URL de tu AASA para forzar una nueva obtención.
• Pruebas de rendimiento: Prueba con cuentas de iCloud que contengan cientos de credenciales para observar la latencia en el mundo real. La superposición del sistema podría mostrar un ligero retraso con muchos passkeys almacenados.

La implementación nativa de passkeys en Android utiliza la API Credential Manager (o la API más antigua de FIDO2 para retrocompatibilidad):

Componentes clave:

• CredentialManager: API central para todas las operaciones de credenciales
• CreatePublicKeyCredentialRequest: Para el registro de passkeys
• GetCredentialRequest: Para la autenticación con passkeys
• Dos modos de interfaz de usuario principales:
  • Inicio de sesión en campo de texto: Campo de nombre de usuario tradicional con el inicio de sesión con passkey que comienza al pulsar un botón
  • Superposición modal de passkey: Diálogo del sistema operativo que lista los passkeys disponibles

Nota: Actualmente, Android carece de las sugerencias de teclado de la Conditional UI de iOS en aplicaciones nativas (aunque la Conditional UI funciona en aplicaciones web).

Implementar passkeys de forma nativa presenta desafíos y lecciones aprendidas importantes. La integración a nivel de sistema operativo puede sacar a la luz problemas en diferentes dispositivos y versiones de SO.

1. Por ejemplo, nuestro equipo se encontró con problemas como el almacenamiento en caché agresivo de Apple del archivo apple-app-site-association (usado para vincular credenciales de app/web) y sutiles diferencias de interfaz de usuario en las solicitudes biométricas de ciertos fabricantes de Android.
2. Además, hay que tener en cuenta que, en algunos escenarios empresariales, los dispositivos gestionados pueden tener la sincronización de passkeys desactivada por política. En entornos corporativos donde la sincronización de iCloud Keychain o Google Password Manager está desactivada, los passkeys quedan vinculados al dispositivo y no se sincronizan, un escenario importante que hay que planificar (por ejemplo, asegurándose de que los usuarios puedan iniciar sesión si cambian de teléfono).
3. Adicionalmente, las aplicaciones de gestión de credenciales de terceros pueden influir en el flujo. Por ejemplo, si un usuario tiene un gestor de contraseñas como 1Password configurado como proveedor de credenciales activo, a menudo interceptará la creación y el almacenamiento de passkeys, teniendo prioridad sobre el gestor de credenciales nativo de la plataforma.

Aunque se pueden implementar passkeys usando las API nativas de la plataforma, los SDKs específicos aceleran significativamente el desarrollo al gestionar la complejidad de WebAuthn, los casos límite y proporcionar telemetría integrada. Los SDKs también ofrecen interfaces simulables para pruebas unitarias (crucial, ya que no se pueden probar datos biométricos en simuladores).

Recomendación: Para implementaciones nativas, recomendamos usar los SDKs de Corbado (SDK de Passkey para iOS en Swift, SDK de Passkey para Android en Kotlin), que gestionan los numerosos casos límite descubiertos a través de despliegues en producción, proporcionan telemetría adicional y facilitan las pruebas.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkeys que millones adoptan, rápidamente. Empieza con la Plataforma de Adopción de Corbado.

Comenzar prueba gratuita

Los System WebView utilizan el componente de navegador nativo de la plataforma para gestionar la autenticación dentro de tu aplicación. A diferencia de las implementaciones totalmente nativas, los System WebView muestran contenido web utilizando el navegador real del sistema (Safari en iOS, Chrome en Android), manteniendo cookies compartidas, credenciales guardadas y los familiares indicadores de seguridad del navegador.

Cuándo elegir System WebView:

• Tu aplicación utiliza inicio de sesión basado en OAuth: System WebView es el enfoque recomendado para flujos OAuth2/OIDC, proporcionando una autenticación segura.
• Ya existe una autenticación basada en web que quieres reutilizar en aplicaciones móviles.
• Necesitas soportar múltiples métodos de autenticación (contraseñas, inicio de sesión social, passkeys) sin tener que reconstruir de forma nativa.
• Quieres mantener una única base de código de autenticación para web y móvil.

Ventajas clave:

• Compatibilidad con OAuth: Diseñado específicamente para flujos de autenticación OAuth/OIDC.
• Indicadores de seguridad: Los usuarios ven la URL real y los certificados SSL, lo que genera confianza.
• Bajo esfuerzo de implementación: Se requiere un código nativo mínimo.
• UX consistente: Interfaz de navegador familiar en la que los usuarios ya confían.

Componentes de la plataforma:

• iOS: ASWebAuthenticationSession (recomendado para flujos de autenticación) o SFSafariViewController (navegación general).
• Android: Chrome Custom Tabs (CCT).

Grandes empresas como Google y GitHub adoptaron este enfoque para añadir el inicio de sesión con passkey a sus aplicaciones móviles mediante superposiciones de WebView sobre las páginas de autenticación web existentes. Esto funciona bien cuando la reconstrucción completa de la autenticación nativa no es factible de inmediato.

iOS proporciona dos componentes principales de System WebView para la autenticación:

ASWebAuthenticationSession (Recomendado para autenticación):

• Diseñado específicamente para flujos OAuth/OIDC y de inicio de sesión seguro.
• Pregunta automáticamente al usuario si la aplicación quiere autenticarse.
• Comparte cookies y credenciales con Safari.
• Soporta passkeys a través de iCloud Keychain.

SFSafariViewController (Navegación general):

• Experiencia completa de Safari dentro de la aplicación.
• Muestra la barra de URL y los indicadores de seguridad.
• No comparte las cookies de Safari en iOS 11+; usa ASWebAuthenticationSession cuando se requiera compartir la sesión de Safari.
• Menos personalizable pero más confiable para los usuarios.

Si tu aplicación utiliza un inicio de sesión basado en OAuth, ASWebAuthenticationSession es la opción recomendada, ya que está diseñada específicamente para escenarios de autenticación y proporciona el mejor equilibrio entre seguridad y experiencia de usuario.

Los Chrome Custom Tabs (CCT) proporcionan una experiencia de autenticación impulsada por Chrome dentro de tu aplicación:

Características clave:

• Comparte cookies y credenciales con el navegador Chrome.
• Muestra la URL y los indicadores de seguridad.
• Permite personalizar el color de la barra de herramientas y la marca.
• Pre-calentamiento para tiempos de carga más rápidos.

Integración con OAuth: Los Chrome Custom Tabs son el equivalente en Android de ASWebAuthenticationSession en iOS, proporcionando un excelente soporte para OAuth mientras se mantiene el acceso a los passkeys almacenados.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Los Embedded WebView proporcionan un control total sobre la renderización del contenido web dentro de tu aplicación, permitiendo la manipulación directa de cookies, sesiones y navegación sin una barra de URL. Sin embargo, este control conlleva requisitos técnicos adicionales para habilitar la funcionalidad de passkeys.

Cuándo elegir Embedded WebView:

• Experiencia similar a la nativa: Tu aplicación ya integra la autenticación dentro de una vista web personalizada para mantener una apariencia nativa, y quieres mantener esta experiencia de usuario consistente.
• Necesidad de control de sesión/cookies: Tu aplicación requiere la manipulación directa de tokens de autenticación y el estado de la sesión después de que se complete la autenticación OAuth.
• Flujo de autenticación existente donde la autenticación con System WebView devuelve un código de autenticación pero no una sesión en contextos embebidos.
• Debes mantener el estado de autenticado a través de múltiples pantallas web embebidas.
• Solo autenticación de primera parte: Tu aplicación gestiona la autenticación directamente. Para implementaciones de passkeys de terceros, consulta aquí.
• AndroidX WebKit 1.12.1+ con detección de características en tiempo de ejecución.
• Aceptas la limitación de Conditional UI para el inicio de sesión (no es compatible en Embedded WebView), no relevante para los ajustes de gestión.

Contexto importante:

Muchas aplicaciones utilizan un enfoque híbrido: System WebView gestiona la autenticación OAuth inicial (donde los passkeys funcionan sin problemas), y luego cambian a Embedded WebView después de la autenticación para gestionar los passkeys en los ajustes. Los desafíos surgen al intentar usar passkeys directamente dentro de los Embedded WebViews.

Requisitos técnicos:

Los Embedded WebViews requieren una configuración adicional en comparación con los System WebViews:

1. iOS: Entitlements de Dominios Asociados, configuración del archivo AASA.
2. Android: AndroidX WebKit 1.12.1+ con configuración de WebAuthn para WebView (se requiere detección de características).
3. Ambos: Archivos de asociación well-known correctamente configurados y Digital Asset Links.

Componentes de la plataforma:

• iOS: WKWebView
• Android: android.webkit.WebView

Ventajas y desventajas:

• Complejidad media: Requiere configuración de WebView (Android WebKit 1.12.1+) y configuración de entitlements (iOS).
• Menor adopción de passkeys: Los usuarios pueden encontrar más fricción en comparación con la implementación nativa.
• Conditional UI no es compatible: El autocompletado de passkeys en los campos de entrada no funciona en Embedded WebView de Android.
• Soporte de plataforma limitado: Algunas características pueden no funcionar de manera consistente (p. ej., creación automática de passkeys).

Al implementar passkeys a través de WebViews, es crucial entender la distinción entre System WebViews y Embedded WebViews. Los tres enfoques descritos anteriormente (Implementación nativa, System WebView y Embedded WebView) sirven para diferentes casos de uso.

En iOS, tienes múltiples opciones para mostrar contenido web dentro de la aplicación:

• WKWebView es un WebView personalizable que forma parte del framework WebKit (introducido en iOS 8). Te da mucho control sobre la apariencia y el comportamiento del contenido web.
• SFSafariViewController es un controlador de vista proporcionado por Apple que actúa como un navegador Safari ligero dentro de tu aplicación. Utiliza el motor de Safari. En iOS 11+, tiene un almacén de cookies separado y no comparte las cookies de Safari. Usa ASWebAuthenticationSession cuando se requiera compartir la sesión de Safari.
• SFAuthenticationSession / ASWebAuthenticationSession son sesiones de autenticación web especializadas (disponibles desde iOS 11/12) destinadas específicamente a flujos de OAuth/OpenID u otros inicios de sesión seguros. También aprovechan Safari internamente, pero se centran en los flujos de autenticación y gestionan automáticamente cosas como las cookies compartidas y el Single Sign-On (SSO).

En Android, las principales opciones son:

• Android WebView es el widget WebView estándar (android.webkit.WebView), que es esencialmente un mini navegador que se puede incrustar en tus actividades. Es muy personalizable pero se ejecuta en el proceso de tu aplicación.
• Chrome Custom Tabs (CCT) es una función que abre una pestaña impulsada por Chrome dentro del contexto de tu aplicación. Las Custom Tabs parecen parte de tu aplicación pero están impulsadas por el navegador Chrome (si está instalado) con características como la precarga, cookies compartidas y la familiar barra de URL para la confianza del usuario.

En las siguientes secciones, profundizaremos un poco más en estos tipos de WebView para iOS y Android, y discutiremos cuál podría ser el más adecuado para los flujos de autenticación con passkeys.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

La plataforma de Apple proporciona las tres opciones de WebView mencionadas anteriormente. Tu elección afectará la fluidez con la que se puedan usar los passkeys dentro de la aplicación:

Para probar el comportamiento de los diferentes WebViews en iOS, recomendamos la aplicación WebView - WKWebView and UIWebView rendering.

WKWebView es un componente WebView versátil para iOS. Los desarrolladores pueden incrustar un WKWebView para renderizar contenido web con un alto grado de control sobre la interfaz de usuario y el comportamiento. WKWebView utiliza el mismo motor de renderizado que Safari, por lo que tiene un gran rendimiento y es compatible con las características web modernas. En teoría, WKWebView puede manejar WebAuthn (y por lo tanto, passkeys) si se configura correctamente, pero ten en cuenta que algunas características avanzadas del navegador pueden estar restringidas por seguridad. Algo a tener en cuenta es que WKWebView, por defecto, no comparte cookies ni datos del llavero con Safari Móvil. Es posible que los usuarios tengan que iniciar sesión de nuevo porque su sesión de WebView está aislada de la sesión de Safari. Además, como el contenido de WKWebView puede ser totalmente personalizado por la aplicación, el usuario no ve una barra de direcciones ni la interfaz de Safari, lo que es genial para la marca, pero significa que el usuario tiene menos pistas para verificar la legitimidad de la página (una preocupación para evitar el phishing). Algunas aplicaciones incluso han abusado de WKWebView para inyectar scripts o alterar contenido (p. ej., se señaló que TikTok inyectaba JS de seguimiento a través de su navegador en la aplicación), por lo que se debe tener cuidado de usar WKWebView de una manera segura y confiable para el usuario.

SFSafariViewController proporciona una experiencia de Safari dentro de la aplicación. Cuando abres una URL con SFSafariViewController, es casi como abrirla en el navegador Safari real, excepto que el usuario permanece dentro de la interfaz de usuario de tu aplicación. La ventaja para los passkeys es significativa: como es esencialmente Safari, el llavero de iCloud del usuario y los passkeys guardados son accesibles. Ten en cuenta que las cookies no se comparten en iOS 11+. Esto significa que si el usuario ya tiene un passkey para tu sitio, Safari puede encontrarlo e incluso mostrar el autocompletado de la Conditional UI para un inicio de sesión fácil. SFSafariViewController es menos personalizable (no puedes cambiar mucho su barra de herramientas), pero gestiona automáticamente muchas características de seguridad y privacidad. Se muestra la barra de URL, con el icono del candado para HTTPS, lo que da a los usuarios la confianza de que están en el dominio correcto. En general, SFSafariViewController se considera más seguro que un WKWebView sin procesar y es más sencillo de implementar (Apple lo proporciona como un componente listo para usar). La principal desventaja es que sacrificas algo de control sobre la apariencia. Para un flujo de autenticación, eso suele ser aceptable. La prioridad aquí es la seguridad y la facilidad de inicio de sesión, en lo que SFSafariViewController sobresale al usar el contexto de Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Estas clases (la última es el nombre más nuevo y amigable con Swift) están diseñadas específicamente para flujos de inicio de sesión como OAuth u OpenID Connect. Cuando necesitas autenticar a un usuario a través de una página web (quizás a un IdP externo), estas sesiones son la opción recomendada en iOS. Son muy similares a SFSafariViewController en que utilizan el navegador Safari internamente y comparten cookies/almacenamiento con Safari. La diferencia clave es que SFAuthenticationSession siempre le pedirá al usuario que la aplicación quiere autenticarse usando una página web (para la conciencia del usuario) y usará automáticamente la sesión de Safari existente del usuario si está disponible.

El beneficio es una experiencia de SSO fluida: si el usuario ya ha iniciado sesión en el proveedor en Safari, esta sesión puede usar esa cookie para evitar otro inicio de sesión. Para los passkeys, esto es importante porque significa que cualquier credencial de passkey almacenada en Safari/iCloud Keychain también se puede usar aquí. La guía oficial de Apple es usar ASWebAuthenticationSession para cualquier cosa que parezca un flujo de inicio de sesión. Las ventajas son una mayor privacidad (tu aplicación nunca ve las credenciales o las cookies, Safari se encarga de ello) y el soporte de SSO integrado. La desventaja es que se limita a los flujos de autenticación (no lo usarías solo para renderizar contenido web arbitrario en tu aplicación). En resumen, si eliges un enfoque de WebView en iOS, ASWebAuthenticationSession suele ser la mejor opción para implementar passkeys porque es seguro, comparte el estado con Safari y está diseñado específicamente para la autenticación.

Want to find out how many people use passkeys?

View Adoption Data

En Android, la decisión sobre WebView se reduce al WebView clásico y los Chrome Custom Tabs:

Para probar el comportamiento de los diferentes WebViews en Android, recomendamos la aplicación WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) es un componente que te permite incrustar páginas web en el diseño de tu actividad. Es similar a WKWebView en que te da control total: puedes interceptar la navegación, inyectar JavaScript, personalizar la interfaz de usuario, etc. También se ejecuta dentro del proceso de tu aplicación. Usar un WebView para passkeys significa que tu aplicación carga tu página de inicio de sesión web, y esa página puede iniciar una ceremonia de passkey con WebAuthn. El WebView de Android moderno sí admite WebAuthn (siempre que la implementación de WebView del dispositivo esté actualizada a través de Android System WebView o el componente de Chrome). Una consideración importante: por defecto, un WebView de Android no comparte cookies ni credenciales almacenadas con el navegador Chrome del usuario. Por lo tanto, cualquier passkey creado o utilizado en el WebView podría no ser conocido por Chrome, y viceversa. Este aislamiento puede ser bueno para la seguridad (tu aplicación no puede leer las cookies del navegador), pero podría obligar a los usuarios a iniciar sesión de nuevo si ya se han autenticado en Chrome. Otro problema es la confianza. Un WebView simple no muestra la URL ni el icono del candado SSL, por lo que los usuarios tienen que confiar completamente en que tu aplicación no les hará phishing. Google incluso ha prohibido el uso de WebView para los inicios de sesión de Google OAuth debido a los riesgos potenciales de phishing. En cuanto al rendimiento, los WebViews están bien, pero pueden ser más lentos o consumir más memoria que usar el navegador predeterminado del usuario, especialmente si se cargan páginas pesadas.

Chrome Custom Tabs (CCT) son un enfoque híbrido. Permiten que tu aplicación abra una página renderizada por Chrome que parece parte de tu aplicación. Puedes personalizar el color de la barra de herramientas, añadir un logo de la aplicación, etc., pero el contenido es renderizado por Chrome en un proceso separado. Para los passkeys, los CCT tienen varios beneficios: comparten las cookies y credenciales del usuario con Chrome, lo que significa que si el usuario tiene un passkey guardado a través de Chrome (Google Password Manager), la Custom Tab puede acceder a él. El usuario también verá la URL real y los indicadores de seguridad, lo que genera confianza. El rendimiento suele ser mejor: Chrome puede ser "precalentado" en segundo plano para una carga más rápida. Y lo que es más importante, la seguridad es fuerte: como es esencialmente la aplicación de Chrome, cosas como Google Safe Browsing protegen la sesión, y tu aplicación no puede inyectar scripts arbitrarios en la página (previniendo ciertos ataques).

La desventaja es que requiere que el usuario tenga Chrome (o un navegador compatible) instalado y actualizado. La mayoría de los usuarios de Android lo tienen, pero en algunos dispositivos de ciertas regiones, esto podría ser un problema. En general, si optas por un enfoque web incrustado en Android, se recomiendan los Chrome Custom Tabs para los flujos de passkeys, ya que proporcionan un buen equilibrio entre integración y seguridad. De hecho, son análogos a SFSafariViewController/ASWebAuthSession de iOS en muchos aspectos: aprovechan el navegador predeterminado para la autenticación.

(Aparte: WKWebView vs SFSafariViewController de Apple y WebView vs CCT de Android tienen muchos paralelismos. Tanto Safari VC como Chrome Tabs comparten el estado del navegador y proporcionan una mejor seguridad, mientras que WKWebView/Android WebView dan más control pero aíslan el contenido web. Para los passkeys, compartir el estado (cookies, almacenes de credenciales) suele ser deseable para que el passkey se pueda acceder y crear sin problemas.)

Independientemente del enfoque de implementación que elijas, se deben cumplir ciertos requisitos técnicos para habilitar la funcionalidad de passkeys. Esta sección proporciona una guía completa sobre cómo configurar los archivos de asociación well-known, los entitlements de iOS y la configuración de WebView en Android.

Nota sobre dispositivos gestionados: El comportamiento de los passkeys cambia significativamente en dispositivos gestionados donde las políticas de gestión de dispositivos móviles (MDM) controlan el almacenamiento de credenciales. Para probar passkeys en dispositivos gestionados, consulta Passkeys en dispositivos gestionados de iOS y Android.

Los flujos nativos y de Embedded WebView requieren archivos de asociación para establecer una confianza criptográfica entre tu aplicación y tu dominio web. System WebView (ASWebAuthenticationSession) y Chrome Custom Tabs no requieren asociación de aplicación a sitio.

El archivo AASA establece la conexión entre tu aplicación de iOS y tu dominio web, permitiendo que los passkeys funcionen en ambas plataformas.

Ubicación del archivo: https://tudominio.com/.well-known/apple-app-site-association

Requisitos de configuración:

• Alojar en /.well-known/apple-app-site-association en tu dominio
• Servir sobre HTTPS con un certificado SSL válido
• Content-Type: application/json
• Sin redirecciones en la ruta .well-known
• Incluir el Team ID y el Bundle ID de tu aplicación

Ejemplo de archivo AASA:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Caché y pruebas de AASA:

Apple almacena en caché los archivos AASA de forma agresiva (hasta 24-48 horas) usando una CDN, lo que puede frustrar el desarrollo y las pruebas. Para evitar la caché durante el desarrollo:

1. Habilita el Modo Desarrollador en tu dispositivo de prueba
2. Añade ?mode=developer a tu dominio asociado en Xcode
3. Esto obliga a iOS a obtener el último archivo AASA directamente de tu servidor

⚠️ Importante: NO uses ?mode=developer en las versiones de producción. Este parámetro es solo para desarrollo; usarlo en producción evitará que iOS detecte correctamente tu archivo AASA, rompiendo la funcionalidad de passkeys.

Validación: Usa el Validador de AASA de Apple para verificar tu configuración.

Android usa Digital Asset Links para verificar la relación entre tu aplicación y tu sitio web.

Ubicación del archivo: https://tudominio.com/.well-known/assetlinks.json

Requisitos de configuración:

• Alojar en /.well-known/assetlinks.json en tu dominio
• Servir sobre HTTPS con un certificado válido
• Content-Type: application/json
• Incluir la huella digital SHA256 de tu aplicación (del certificado de firma)

Ejemplo de archivo assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Validación: Usa el Generador de Digital Asset Links de Google para crear y verificar tu configuración.

Las aplicaciones de iOS requieren los entitlements adecuados para acceder a la funcionalidad de passkeys. Los requisitos difieren ligeramente según tu enfoque de implementación.

El archivo de entitlements (a menudo llamado Runner.entitlements en aplicaciones de Flutter o TuApp.entitlements en proyectos nativos de iOS) define permisos y capacidades especiales otorgados por el sistema de Apple. Para los passkeys, este archivo configura los Dominios Asociados.

Ubicación del archivo: Típicamente en tu proyecto de Xcode en ios/Runner/Runner.entitlements

La implementación nativa y el Embedded WebView requieren la capacidad de Dominios Asociados para vincular tu aplicación con tu dominio web. System WebView (ASWebAuthenticationSession) no requiere esto ya que se ejecuta en el contexto de Safari.

Configuración en Xcode:

1. Abre tu proyecto en Xcode
2. Selecciona tu target de la aplicación
3. Ve a la pestaña "Signing & Capabilities"
4. Haz clic en "+ Capability" y añade "Associated Domains"
5. Añade tu dominio con el prefijo webcredentials:

Ejemplo de configuración:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:tudominio.com</string>
        <string>webcredentials:subdominio.tudominio.com</string>
    </array>
</dict>
</plist>

Múltiples dominios: Si tu aplicación necesita funcionar con múltiples dominios, es posible que necesites Related Origin Requests (ROR).

Los Embedded WebViews de Android obtuvieron soporte nativo para WebAuthn con AndroidX WebKit 1.12, eliminando la necesidad de código de puente de JavaScript personalizado. System WebView (Chrome Custom Tabs) no requiere ninguna configuración, las credenciales funcionan automáticamente.

Requisitos:

• AndroidX WebKit 1.12.1 o más reciente (1.14.0+ recomendado)
• Digital Asset Links configurados
• APK de WebView con soporte para WebAuthn (verificar mediante detección de características)
• Nota: La biblioteca de credenciales de AndroidX NO es necesaria para WebAuthn en WebView, solo para implementaciones totalmente nativas

Implementación:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Comprobar si se admite la autenticación web
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Habilitar la autenticación web
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Habilitar JavaScript
    webView.settings.javaScriptEnabled = true
}

Puntos clave:

• No se necesita puente de JavaScript: WebAuthn funciona de forma nativa en WebView
• Se requiere detección de características: Comprueba siempre WebViewFeature.WEB_AUTHENTICATION en tiempo de ejecución
• Conditional UI no es compatible: mediation:"conditional" (autocompletado de passkeys en campos de entrada) no funciona en Embedded WebView
• Estrategia de respaldo: Si la característica no está disponible, usa Chrome Custom Tabs en su lugar

Notas de versión:

• Usa WebKit 1.12.1 o más reciente (1.12.0 tenía un problema de disponibilidad en tiempo de ejecución)
• El soporte de la característica depende de la versión del APK de WebView del usuario; las APK más antiguas en el dispositivo no expondrán la característica

Antes de AndroidX WebKit 1.12.0, no existía soporte nativo para WebAuthn en Embedded WebView. Los equipos tenían que:

1. Usar Chrome Custom Tabs o Auth Tab (recomendado)
2. Construir un puente de JavaScript personalizado

Si necesitas dar soporte a versiones de Android más antiguas o a dispositivos sin APK de WebView actualizadas, consulta la guía de integración de Credential Manager WebView de Android para el enfoque del código de puente. Sin embargo, recomendamos encarecidamente usar el enfoque nativo de WebKit 1.12.1+ para las aplicaciones modernas.

Recomendación: Usa el soporte nativo de WebAuthn con AndroidX WebKit 1.12.1+. Si no está disponible en tiempo de ejecución, recurre a Chrome Custom Tabs, que proporciona un excelente soporte de passkeys con credenciales compartidas.

Al implementar passkeys en aplicaciones nativas, necesitas establecer confianza entre tu aplicación y tu(s) dominio(s) web. Esta sección cubre cómo manejar dominios únicos, múltiples dominios relacionados (ROR) y cómo verificar que tus archivos de asociación well-known estén configurados correctamente.

Para aplicaciones que usan un solo dominio (p. ej., kayak.com), necesitas:

• Un archivo AASA para iOS en https://kayak.com/.well-known/apple-app-site-association
• Un archivo assetlinks.json para Android en https://kayak.com/.well-known/assetlinks.json
• Entitlement de Dominios Asociados configurado con webcredentials:kayak.com

Related Origins (ROR) es una característica de WebAuthn que permite que un único conjunto de passkeys funcione en múltiples dominios relacionados (p. ej., kayak.com, kayak.de, kayak.co.uk). ROR utiliza el endpoint /.well-known/webauthn en cada sitio para definir orígenes relacionados, NO los archivos AASA o assetlinks.

Puntos clave:

• Configuración de ROR: Cada dominio aloja /.well-known/webauthn con la lista de orígenes relacionados
• Archivos de asociación de la aplicación (AASA/assetlinks): Se usan solo para mapear aplicaciones a sus sitios web correspondientes
• Embedded WebView en iOS 18+: Soporta ROR cuando está configurado correctamente
• Entitlements de Dominios Asociados: Incluye todos los dominios con los que tu aplicación necesita autenticarse

Ejemplo de configuración:

Si tu aplicación funciona con kayak.com y kayak.de, ambos dominios deben:

• Alojar sus respectivos archivos AASA con el mismo Team ID y Bundle ID
• Estar listados en los entitlements de Dominios Asociados de tu aplicación
• Tener archivos well-known correctamente configurados y accesibles

Antes de lanzar, verifica que tus archivos well-known estén configurados y accesibles correctamente. Apple y Google proporcionan URL de prueba basadas en CDN para comprobar la disponibilidad de los archivos:

Uso de estas URL de prueba:

• Haz clic en los enlaces para verificar si Apple/Google pueden recuperar tus archivos well-known
• El parámetro ?nocache=1 de Apple fuerza una recuperación nueva, evitando la caché de la CDN
• Si los archivos no son accesibles a través de estas URL, la funcionalidad de passkeys no funcionará en tu aplicación
• Reemplaza kayak.com o kayak.de con tu(s) propio(s) dominio(s) en los patrones de URL anteriores

Advertencia sobre las pruebas: Asegúrate de que todos los dominios tengan archivos well-known configurados correctamente. Un archivo faltante o mal configurado en cualquier dominio puede romper la funcionalidad de passkeys para ese dominio.

Más información: WebAuthn Relying Party ID en aplicaciones nativas

Elegir el enfoque de implementación correcto depende de la arquitectura de autenticación de tu aplicación, los requisitos de OAuth y la necesidad de control de sesión. Usa este árbol de decisiones para determinar el mejor camino a seguir.

Comienza con estas preguntas clave:

1. ¿Tu aplicación utiliza inicio de sesión basado en OAuth (OAuth2, OIDC, proveedores de inicio de sesión social)?

   • Sí → System WebView (Sección 1.2)
     • iOS: Usa ASWebAuthenticationSession
     • Android: Usa Chrome Custom Tabs
     • Excelente soporte de OAuth con credenciales compartidas

2. ¿Quieres reutilizar la autenticación web en una apariencia similar a la nativa (sin barra de URL, control total de la interfaz de usuario)?

   • Sí → Embedded WebView (Sección 1.3) con configuración
     • iOS: WKWebView + entitlements de Dominios Asociados
     • Android: WebView + configuración de AndroidX WebKit 1.12.1+
     • Proporciona una apariencia similar a la nativa mientras reutiliza componentes web
     • Nota: Conditional UI no es compatible en Embedded WebView
   • No → Considera System WebView o Nativo

3. ¿Estás creando una nueva aplicación nativa o tienes pantallas de inicio de sesión nativas?

   • Sí → Implementación nativa (Sección 1.1)
     • Mejor experiencia de usuario
     • Autenticación instantánea y silenciosa
     • Requiere desarrollo específico para cada plataforma

4. ¿Tienes una autenticación web existente que quieres reutilizar?

   • Sí → System WebView para una implementación rápida
   • No → Implementación nativa para una UX óptima

Así es como se desempeña cada enfoque en dimensiones clave:

Explicación de las dimensiones:

• Crear Passkeys: Con qué facilidad los usuarios pueden crear passkeys a través de este enfoque.
• Usar Passkeys: La experiencia de autenticación al usar passkeys existentes.
• Gestionar Passkeys: Cómo los usuarios ven, editan o eliminan passkeys.
• Complejidad técnica: Esfuerzo de desarrollo y mantenimiento continuo.
• Soporte OAuth: Qué tan bien el enfoque maneja los flujos de autenticación OAuth2/OIDC.
• Tiempo de configuración: Cronograma de implementación típico.

Recomendado: System WebView

Si tu aplicación se autentica a través de OAuth2, OIDC o proveedores de inicio de sesión social (Google, GitHub, Microsoft, etc.), System WebView es la opción óptima:

• iOS: ASWebAuthenticationSession está diseñado específicamente para flujos de OAuth.
• Android: Chrome Custom Tabs proporcionan una integración de OAuth fluida.
• Beneficios: Código nativo mínimo, uso compartido automático de credenciales.
• Implementación: Añade WebAuthn a tu página de autenticación web y luego cárgala a través de System WebView.

Ejemplo: Aplicaciones de viajes como kayak.com y kayak.de usan OAuth para la autenticación. System WebView les permite mantener su infraestructura OAuth existente mientras añaden soporte para passkeys a través de sus páginas de autenticación web.

Recomendado: Enfoque híbrido

Usa System WebView para la autenticación OAuth inicial, y luego Embedded WebView para las sesiones posteriores a la autenticación:

1. Autenticación inicial: System WebView gestiona el inicio de sesión con OAuth + passkey.
2. Gestión de sesión: Cambia a Embedded WebView para contenido web autenticado donde necesitas control de cookies/sesión.
3. Configuración técnica: Configura los requisitos tanto para System WebView como para Embedded WebView; para Android, asegúrate de que AndroidX WebKit 1.12.1+ esté incluido (ver Sección 5).

Cuándo usarlo: Aplicaciones que se autentican a través de OAuth pero que luego necesitan mostrar contenido web autenticado donde se requiere manipulación directa de la sesión.

Recomendado: Implementación nativa

¿Estás construyendo desde cero o tienes pantallas nativas? Opta por lo totalmente nativo:

• iOS: Usa el framework AuthenticationServices.
• Android: Usa la API de Credential Manager.
• Beneficios: La mejor UX, autenticación instantánea, control total.
• Ventaja única: Usa preferImmediatelyAvailableCredentials para mostrar una superposición automática de passkeys al iniciar la aplicación - exclusivo de las implementaciones nativas y que proporciona las tasas de conversión más altas.
• Recomendación de SDK: Usa los SDKs de Corbado (iOS, Android) para acelerar el desarrollo con manejo de casos límite probado en producción.

Para nuevas aplicaciones: Recomendamos encarecidamente construir un inicio de sesión nativo desde el primer día. Esto te prepara para una UX óptima y evita futuras migraciones de WebView a nativo.

Recomendado: Migración por fases

• Fase 1: Passkeys con System WebView - Añade soporte para passkeys al inicio de sesión web existente, cárgalo a través de System WebView (ASWebAuthenticationSession/Chrome Custom Tabs). Una victoria rápida con un código nativo mínimo.
• Fase 2: Interceptación nativa - Añade una comprobación de passkey nativa antes de mostrar el WebView. Ejemplo: kayak.com intenta la autenticación con passkey nativa primero, y recurre a WebView si es necesario. Proporciona un inicio de sesión biométrico rápido manteniendo la retrocompatibilidad.
• Fase 3: Totalmente nativo - Migra gradualmente a la autenticación nativa para los usuarios de passkeys, manteniendo el WebView para los métodos heredados.

Este enfoque por fases permite mejoras incrementales sin interrumpir a los usuarios existentes.

Consulta la Sección 5 para obtener instrucciones de configuración detalladas.

Probar los passkeys en aplicaciones nativas requiere un enfoque estructurado y de múltiples capas. Sigue la pirámide de pruebas: pruebas unitarias (lógica aislada), pruebas de integración (ceremonia de WebAuthn en simuladores/emuladores) y pruebas de sistema (de extremo a extremo en dispositivos físicos).

Categorías de prueba esenciales:

• Flujos principales: Registro, autenticación, flujos entre dispositivos, eliminación de passkeys.
• Cobertura de plataformas: iOS (nativo), Android (nativo), navegadores web en diferentes versiones de SO.
• Asociación de dominios: Verificar que los archivos AASA (iOS) y Digital Asset Links (Android) sean accesibles.
• Flujos de cancelación: Probar la cancelación del usuario en las solicitudes del SO y las pantallas biométricas.
• Manejo de errores: Fallos del backend, tiempos de espera de red, credenciales no coincidentes.
• Casos límite: Bloqueo de pantalla desactivado, iCloud/Google Password Manager desactivado.
• Flujos de OAuth: Integración completa de OAuth + passkey de extremo a extremo.
• Dispositivos gestionados: Entornos controlados por MDM (consulta pruebas en dispositivos gestionados).
• Gestores de terceros: Compatibilidad con 1Password, Bitwarden, Dashlane.
• Autenticación entre dispositivos: Flujos de código QR y pruebas de transporte híbrido.
• Específico de Embedded WebView: Si usas Embedded WebView, verifica la configuración de WebKit 1.12.1+ en Android.
• Monitorización en producción: Panel de control para tasas de éxito, fallos y latencia.

Para una guía completa de pruebas que incluye estrategias de automatización, problemas específicos de cada plataforma y una lista de verificación completa antes del lanzamiento, consulta nuestra guía dedicada: Prueba de flujos de Passkey en aplicaciones nativas de iOS y Android.

Considera la posibilidad de pedir a los usuarios que creen passkeys después de un inicio de sesión tradicional exitoso (contraseña, OAuth). Este enfoque de conversión gradual:

• No interrumpe los flujos de autenticación existentes.
• Permite una degradación elegante si el usuario se niega.
• Aumenta la adopción de passkeys con el tiempo sin forzar cambios.
• Funciona bien con los tres enfoques de implementación.

Ejemplo: Después del inicio de sesión con OAuth a través de System WebView, muestra un aviso nativo: "¿Habilitar un inicio de sesión más rápido con Face ID?". Si se acepta, crea el passkey a través de la página web cargada en System WebView.

Decidir cómo implementar los passkeys (mediante una implementación nativa, System WebView o Embedded WebView) es una elección de diseño crucial que afecta la seguridad, la experiencia del usuario y la complejidad del desarrollo. No hay una respuesta única para todos.

Para aplicaciones basadas en OAuth: System WebView (ASWebAuthenticationSession, Chrome Custom Tabs) es el punto de partida recomendado. Proporciona un excelente soporte para OAuth, un esfuerzo de implementación mínimo y el uso compartido automático de credenciales.

Para aplicaciones principalmente nativas: Ve a por lo nativo más pronto que tarde. Un inicio de sesión con passkey nativo ofrece la UX más fluida con capacidades exclusivas como preferImmediatelyAvailableCredentials, que permite una superposición automática de passkeys al iniciar la aplicación, algo que las implementaciones de WebView no pueden proporcionar. Con iOS y Android ofreciendo ahora soporte de primera clase para passkeys, los éxitos en el mundo real demuestran una alta adopción. Las herramientas (incluidos los SDK de código abierto y las bibliotecas de la plataforma) han madurado para hacer que la integración nativa sea factible en plazos razonables. Si bien debes tener en cuenta las políticas de gestión de dispositivos, la sincronización entre dispositivos y los proveedores de terceros, estos desafíos se pueden gestionar con una ingeniería y pruebas cuidadosas. El resultado es un inicio de sesión de la aplicación que deleita a los usuarios por su facilidad y velocidad, al tiempo que mejora significativamente la seguridad.

Para los requisitos del marco de Embedded WebView: Embedded WebView se usa comúnmente en dos escenarios del mundo real. Primero, las aplicaciones basadas en OAuth a menudo usan System WebView para el flujo de inicio de sesión inicial, y luego cambian a Embedded WebView para renderizar las opciones de gestión de passkeys en las pantallas de configuración donde se necesita control de la sesión, aunque algunas aplicaciones simplifican esto manteniendo System WebView para ambos flujos. Segundo, las aplicaciones que ya incrustaron su flujo de autenticación en marcos de WebView antes de adoptar passkeys continúan este patrón por consistencia. Embedded WebView con soporte nativo de WebAuthn (AndroidX WebKit 1.12.1+) requiere configuración (permisos, entitlements, ajustes de WebView) pero ya no necesita código de puente de JavaScript personalizado. Ten en cuenta que Conditional UI no es compatible en Embedded WebView. Elige este enfoque cuando mantengas patrones de autenticación incrustados existentes o cuando necesites control de sesión/cookies para las pantallas posteriores a la autenticación.

En última instancia, los passkeys en aplicaciones nativas representan un gran salto adelante tanto en la comodidad del usuario como en la seguridad. Ya sea que se implementen a través de Nativo, System WebView o Embedded WebView, eliminan los riesgos de phishing y las cargas de la gestión de contraseñas para tus usuarios. Las implementaciones en el mundo real como la integración de passkeys en la aplicación nativa de VicRoads demuestran que los enfoques principalmente nativos ofrecen la mayor adopción y satisfacción del usuario cuando se ejecutan correctamente con características como las superposiciones automáticas de passkeys. Siguiendo las mejores prácticas para una autenticación amigable para el usuario y eligiendo el enfoque de implementación que se ajuste a la arquitectura de tu aplicación (nativo para nuevas aplicaciones, System WebView para flujos de OAuth o Embedded WebView para patrones incrustados existentes), puedes ofrecer inicios de sesión biométricos sin contraseña que realmente hagan realidad la visión de los passkeys: una autenticación simple, segura y agradable para todos.

Si los passkeys no funcionan en tu aplicación nativa, verifica estos problemas comunes según el enfoque de implementación:

• Archivos servidos a través de HTTPS con un certificado válido.
• Tipo MIME correcto: application/json.
• Sin redirecciones en la ruta .well-known.
• iOS: El Team ID y el Bundle ID coinciden exactamente en el archivo AASA.
• Android: La huella digital SHA256 coincide con tu certificado de firma en assetlinks.json.
• El ID de la Relying Party coincide con tu dominio (sin protocolo, sin puerto).
• Sin barras finales en el RP ID.
• Origen de WebAuthn: https://tu-dominio.com (no app://).

• iOS: Capacidad de Dominios Asociados habilitada en Xcode con webcredentials:tudominio.com.
• Android: Digital Asset Links declarados en AndroidManifest.xml.
• El usuario tiene el bloqueo de pantalla habilitado (biométrico o PIN).
• Prueba con el Validador de AASA de Apple y la herramienta de Digital Asset Links de Google.
• Verifica que el archivo Runner.entitlements contenga los dominios asociados correctos.

• iOS: Usando ASWebAuthenticationSession (recomendado) o SFSafariViewController.
• Android: Usando Chrome Custom Tabs (no un WebView simple).
• iOS: Verifica que los Dominios Asociados estén configurados si es necesario.
• Prueba que las cookies/credenciales se compartan con el navegador del sistema.
• Verifica que la página de autenticación web tenga una implementación de WebAuthn adecuada.

• iOS: Configurado con los entitlements adecuados.
• iOS: Los Dominios Asociados incluyen todos los dominios relevantes.
• iOS: El archivo AASA es accesible y está formateado correctamente.
• iOS: Prueba con ?mode=developer durante el desarrollo (eliminar para producción).
• Android: AndroidX WebKit 1.12.1+ (o más reciente) incluido en el proyecto.
• Android: Verificación en tiempo de ejecución de la característica WebViewFeature.WEB_AUTHENTICATION.
• Android: Se llama a setWebAuthenticationSupport() con WEB_AUTHENTICATION_SUPPORT_FOR_APP.
• Android: JavaScript habilitado en la configuración de WebView.
• Android: La versión del APK de WebView del usuario admite la característica WebAuthn (usa la detección de características, no la versión del SO).
• No se utiliza Conditional UI (no es compatible en Embedded WebView).
• Recurrir a Chrome Custom Tabs si la característica WebAuthn no está disponible.

• Verifica si el usuario tiene un proveedor de credenciales no predeterminado activo (1Password, Bitwarden, etc.).
• Verifica que el proveedor admita passkeys (no todos los gestores de contraseñas lo hacen).
• Prueba con el gestor de credenciales nativo de la plataforma (iCloud Keychain, Google Password Manager).

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Generalmente significa: Faltan entitlements (iOS) o la característica de WebView no está disponible/habilitada (Android Embedded WebView).
• Verifica: Configuración de Dominios Asociados, accesibilidad del archivo AASA, versión de WebKit, detección de características, llamada a setWebAuthenticationSupport().

No aparece el aviso de passkey

• Podría significar: AASA/assetlinks.json no se está cargando, tipo de WebView incorrecto, archivo AASA en caché.
• Intenta: Validar los archivos de asociación, usar ?mode=developer en iOS para las pruebas, verificar el tipo de WebView.

Para una depuración detallada, consulta nuestro artículo sobre IDs de Relying Party en aplicaciones nativas.

SDKs nativos de Corbado:

• SDK de iOS (Swift)
• SDK de Android (Kotlin)
• Paquete de Flutter

Documentación de la plataforma:

• Apple: Supporting Passkeys
• Google: Credential Manager

Herramientas de validación:

• Validador de AASA de Apple
• Generador de Digital Asset Links de Google