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

Este artículo explica cómo implementar passkeys en aplicaciones nativas (iOS + Android). Aprenderás qué tipo de WebView se recomienda para la autenticación con passkeys.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Opciones de implementación de passkeys en aplicaciones nativas#

La autenticación se erige como el centinela, salvaguardando los datos del usuario y garantizando interacciones seguras dentro de las aplicaciones nativas. La llegada de las passkeys ha revolucionado este espacio, ofreciendo un mecanismo de autenticación robusto y fácil de usar. Hay dos formas principales de integrar passkeys en una aplicación nativa, ya sea mediante una implementación nativa o a través de un WebView. Primero echemos un vistazo y veamos cómo se comparan ambas formas.

1.1 Implementación nativa: Gran experiencia de usuario#

Una implementación nativa a menudo se considera que proporciona la mejor experiencia de usuario dentro de una aplicación. Se caracteriza por sus interacciones de usuario fluidas, integradas y cohesivas, adaptadas precisamente al entorno del sistema operativo, ya sea iOS o Android. El requisito para una implementación 100% nativa es volverse 100% sin contraseña y ser verdaderamente nativo en passkeys. Este enfoque te libera de la posible fricción de la transición entre la aplicación nativa y el contenido web (mostrado a través de un WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Implementación de WebView: Experiencia similar a un navegador#

Al desarrollar una aplicación nativa, el camino para ser completamente nativo no siempre es posible. En escenarios donde todavía necesitas admitir la autenticación basada en contraseñas utilizando OAuth2, una integración nativa completa puede no ser factible, haciendo de las implementaciones de WebView la única alternativa viable. WebView actúa como un puente, incrustando contenido web directamente dentro de tu aplicación, proporcionando una experiencia de usuario similar a la de un navegador mientras se navega por páginas web. Esto es particularmente pertinente si eres un proveedor de OAuth2, tu solución de autenticación subyacente está basada en OAuth2 o si tu solución de inicio de sesión utiliza inicios de sesión sociales a través de terceros, como Google o GitHub. En estos casos, emplear un WebView se vuelve inevitable debido a la necesidad de interactuar con contenido web y gestionar varios flujos de autenticación de usuario, especialmente cuando se requieren asociaciones de aplicaciones nativas.

En esencia, mientras que las implementaciones nativas ofrecen una experiencia de usuario fluida e inigualable, no siempre son una opción viable, especialmente cuando se combinan con soluciones de autenticación basadas en contraseñas o en OAuth2. Por otro lado, las implementaciones de WebView proporcionan una vía flexible, aunque ligeramente menos fluida, para integrar contenido web y gestionar la autenticación de usuario dentro de tu aplicación, asegurando que puedas navegar por las complejidades de varios flujos de autenticación e inicios de sesión de terceros.

Las siguientes secciones de este artículo se centran en la implementación a través de WebView. Para obtener más información sobre la integración nativa de passkeys, consulta aquí.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Más de 10,000 desarrolladores confían en Corbado y hacen que Internet sea más seguro con passkeys. ¿Tienes preguntas? Hemos escrito más de 150 artículos de blog sobre passkeys.

Únete a la Comunidad de Passkeys

2. Resumen de las opciones de WebView#

Navegando por el laberinto de la autenticación en aplicaciones nativas, los desarrolladores y gerentes de producto se encuentran con una decisión crucial: implementar la autenticación con passkeys de forma nativa o a través de WebView. Si se decide por esta última, tanto las plataformas iOS como Android ofrecen dos tipos distintos de WebViews, cada uno con sus atributos únicos y posibles casos de uso.

2.1 WebViews de iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (diseñado específicamente para flujos de autenticación basados en OAuth / OpenID Connect)

En las siguientes secciones, profundizamos en estos tipos de WebView y, en última instancia, te guiamos hacia una decisión informada sobre qué WebView emplear para la autenticación con passkeys en tus aplicaciones nativas (si la implementación puramente nativa no es una alternativa).

Subscribe to our Passkeys Substack for the latest news.

3. WebViews en iOS#

Los WebViews de iOS son WKWebView o SFSafariViewController (si se trabaja con OAuth / OIDC, es SFAuthenticationSession / ASWebAuthenticationSession).

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

3.1 WKWebView#

WKWebView es una opción de WebView potente y versátil disponible para los desarrolladores de iOS. Introducido con iOS 8, permite a los desarrolladores incrustar contenido web directamente dentro de una aplicación, proporcionando una amplia gama de opciones de personalización y configuración. WKWebView es conocido por su rendimiento, utilizando el mismo motor de renderizado web que Safari, y ofreciendo un rico conjunto de APIs para interactuar con el contenido web, gestionar la navegación, las interacciones del usuario y más.

3.2 SFSafariViewController#

SFSafariViewController es un WebView que permite a los desarrolladores aprovechar las capacidades de Safari directamente dentro de sus aplicaciones. Proporciona una experiencia de usuario fluida al utilizar la configuración de Safari del usuario, como contraseñas guardadas, passkeys, cookies y más, asegurando una navegación web consistente, porque en realidad se ejecuta como la aplicación Safari. SFSafariViewController no es tan personalizable como WKWebView, pero ofrece características de seguridad mejoradas y facilidad de uso, lo que lo convierte en una opción preferida para mostrar contenido web sencillo dentro de las aplicaciones.

	WKWebView	SFSafariViewController
Experiencia de usuario	- Sensación nativa: Los usuarios pueden sentir que el contenido web es una parte nativa de la aplicación porque los desarrolladores pueden personalizar la apariencia para que coincida con el diseño de la aplicación. - Autocompletar: Es posible autocompletar con datos de Safari	- Fluida: Experiencia de usuario fluida utilizando la configuración de Safari del usuario, asegurando una navegación web consistente entre la aplicación nativa y el navegador.
Experiencia de desarrollador	- Altamente personalizable: Amplia personalización y configuración disponibles - Flexible: Muchas APIs para interactuar con el contenido web	- Medianamente personalizable: Opciones de personalización limitadas, especialmente en comparación con WKWebView, - Simple: Más simple de implementar en comparación con WKWebView
Rendimiento	- Más bien lento: Dependiendo de la implementación y el contenido web, las velocidades de carga se pueden optimizar, pero aún pueden ser más lentas en comparación con SFSafariViewController debido al procesamiento adicional de características e interacciones personalizadas.	- Más bien rápido: Típicamente ofrece un mejor rendimiento ya que aprovecha el motor de Safari, que está optimizado para velocidad y eficiencia, proporcionando tiempos de carga rápidos para las páginas web.
Confianza y reconocimiento	- No se requiere mostrar la URL: WKWebView a menudo no muestra la URL, lo que dificulta que los usuarios verifiquen la página web. Potencial para que aplicaciones maliciosas imiten este comportamiento y hagan phishing de credenciales.	- Experiencia similar a un navegador: Renderiza páginas web usando Safari, proporcionando una experiencia "similar a un navegador". Los usuarios pueden ver la URL y acceder a las funciones de autocompletar de Safari, lo que potencialmente infunde más confianza debido a la interfaz familiar.
Aislamiento	- Separado: Las cookies y las sesiones están separadas de Safari; los usuarios no iniciarán sesión automáticamente en un WKWebView.	- Separado: Las cookies y las sesiones están separadas de Safari; los usuarios tampoco iniciarán sesión automáticamente en SFSafariViewController.
Vulnerabilidades	- Seguro: Intrínsecamente seguro debido al sandboxing de aplicaciones de Apple, pero el comportamiento y la seguridad dependen de la implementación de la aplicación. Vulnerabilidades potenciales si no se implementa correctamente.	- Más seguro: Se beneficia de las características de seguridad integradas de Safari, incluidas las advertencias contra phishing y sitios web maliciosos. Generalmente se considera más seguro para mostrar contenido web que WKWebView debido a estas características y la familiaridad del usuario con Safari.
Otros	- Características no disponibles: Algunas características del navegador (p. ej., WebAuthn) pueden no ser totalmente accesibles debido a preocupaciones de seguridad y a que WKWebView se ejecuta en el contexto de la aplicación. - Inyección de JavaScript: Algunas aplicaciones, p. ej., TikTok, inyectan JavaScript de seguimiento en su WKWebView dentro de la aplicación, o restringen el control del usuario (p. ej., Facebook) - Problemas de privacidad: Más comentarios de la comunidad sobre la privacidad	- Sin inyección de JavaScript: No permite la ejecución de JavaScript desde la aplicación, mejorando la seguridad y la privacidad. Tampoco admite alertas o confirmaciones de JavaScript, lo que podría afectar la experiencia del usuario en ciertas páginas web. - Modo Lector: Proporciona un modo lector para una versión limpia y fácil de leer de los artículos.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession y ASWebAuthenticationSession son WebViews diseñados específicamente para flujos de autenticación basados en OAuth / OpenID Connect. Proporcionan un espacio seguro y aislado para la autenticación del usuario, salvaguardando las credenciales del usuario y asegurando que la información privada no se comparta inadvertidamente con la aplicación. Estas sesiones comparten cookies y datos de sitios web con Safari, proporcionando una experiencia de usuario consistente y fluida, especialmente durante los procesos de autenticación.

Pros:

Autenticación dedicada: Diseñado específicamente para flujos de autenticación basados en OAuth / OpenID Connect, asegurando un proceso de autenticación optimizado.
Protección de la privacidad: Asegura la privacidad de los datos del usuario al no compartir cookies o datos de sitios web con la aplicación.
Soporte para SSO: Admite Single Sign-On, proporcionando una experiencia de usuario conveniente.

Contras:

Caso de uso limitado : Se centra principalmente en la autenticación con OAuth / OpenID Connect, lo que podría no ser adecuado para todos los casos de uso.

Cuando la tarea principal es la autenticación del usuario, especialmente al implementar SSO o interactuar con proveedores de OAuth, debes usar SFAuthenticationSession / ASWebAuthenticationSession en lugar de SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebViews en Android#

Los WebViews de Android son WebView o Chrome Custom Tabs (CCT). Para probar el comportamiento de los diferentes WebViews en Android, recomendamos la aplicación WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView en Android es un componente completo que permite a los desarrolladores mostrar contenido web como parte de la interfaz de usuario de la aplicación. Es versátil, ofrece una amplia gama de opciones de personalización y proporciona a los desarrolladores la flexibilidad para configurar el WebView para adaptarse a diversas necesidades. WebView proporciona un rico conjunto de APIs para interactuar con el contenido web, gestionar las interacciones del usuario e incluso manejar diálogos de JavaScript, certificados de cliente y solicitudes de permisos.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) ofrece una forma fluida, segura y eficiente de integrar contenido web directamente en tu aplicación. Al aprovechar las capacidades y características de seguridad de Chrome, CCT proporciona una experiencia de usuario que es tanto consistente como de alto rendimiento.

CCT es un componente del navegador Chrome, diseñado para integrarse con el framework de Android, permitiendo que las aplicaciones abran contenido web en un proceso ligero y dedicado. Notablemente, se abre más rápido que un navegador convencional y, cuando se precarga a través de su llamada de calentamiento, potencialmente supera a un WebView. Aunque ejecuta JavaScript, opera en su propio proceso, protegiendo a las aplicaciones de la ejecución de código malicioso. Además, la interfaz de usuario de CCT proporciona una barra de acción, mostrando la URL y un icono de candado de verificación SSL para páginas seguras, tranquilizando así a los usuarios sobre la autenticidad y seguridad de la página que se está cargando.

En general, se puede decir que iOS WKWebView y Android WebView, así como SFSafariViewController y Chrome Custom Tabs (CCT) son similares.

Característica	WebView	Chrome Custom Tab
Experiencia de usuario	- Flexibilidad: Proporciona un rico conjunto de APIs para interactuar con el contenido web y gestionar las interacciones del usuario, incluido el manejo de diálogos de JavaScript y solicitudes de permisos. - Consistencia: Gestionar una experiencia de usuario consistente, especialmente con contenido web variado, puede ser un desafío.	- Características del navegador: Comparte características como el Ahorro de datos y el Autocompletar sincronizado entre dispositivos. - Botón de retroceso: Permite a los usuarios volver fácilmente a la aplicación con un botón de retroceso integrado. - Dependencia: Depende de la aplicación de Chrome, que podría no estar disponible o actualizada en todos los dispositivos de los usuarios - Redirección al navegador: Ciertas funcionalidades podrían redirigir a los usuarios a la aplicación de Chrome, interrumpiendo potencialmente la experiencia del usuario. - Pestañas personalizadas parciales: Solo una parte de la pantalla se puede usar para la Chrome Custom Tab mientras que el resto muestra la aplicación nativa - Hoja lateral: En modo horizontal y en dispositivos de pantalla grande, la Chrome Custom Tab solo se muestra en un lado de la pantalla, mientras que el resto de la pantalla muestra la aplicación nativa
Experiencia de desarrollador	- Altamente personalizable: Ofrece amplias opciones/necesidades de personalización. - Interactividad: Proporciona numerosas APIs para interactuar con el contenido web y gestionar las interacciones del usuario.	- Personalizable: Permite la personalización del color de la barra de herramientas, el botón de acción, la barra de herramientas inferior, los elementos del menú personalizados y las animaciones de entrada/salida. - Callback: Entrega un callback a la aplicación tras una navegación externa. - Características de seguridad: Proporciona características listas para usar, eliminando la necesidad de gestionar solicitudes, concesiones de permisos o almacenes de cookies.
Rendimiento	- Rendimiento mediocre: Puede que no ofrezca el mismo nivel de rendimiento que las Chrome Custom Tabs (CCT)	- Precalentamiento: Incluye el precalentamiento del navegador en segundo plano y la carga especulativa de URLs para mejorar el tiempo de carga de la página. - Prioridad: Evita que las aplicaciones que lanzan una Custom Tab sean desalojadas durante su uso al elevar su importancia al nivel de "primer plano".
Confianza y reconocimiento	- URL y SSL no visibles: La información de la URL y el SSL no es inherentemente visible en un WebView. A menos que el desarrollador de la aplicación implemente estas características, los usuarios no sabrán si están en el sitio web correcto o en uno de phishing.	- URL y SSL visibles: Utiliza el navegador Chrome real para renderizar las páginas. Los usuarios pueden ver la URL y el certificado SSL (indicando si la conexión es segura). Esto puede proporcionar a los usuarios la confianza de que no están en un sitio de phishing.
Aislamiento	- Se ejecuta dentro del proceso de la aplicación: Si una aplicación tiene una vulnerabilidad que permite la ejecución de código malicioso, existe el riesgo de que el WebView pueda ser comprometido. Sin embargo, WebView también recibe actualizaciones, pero su comportamiento y seguridad pueden depender más de la aplicación que lo utiliza. - Sin compartición de cookies/sesiones: No comparte cookies o sesiones con el navegador principal del dispositivo, ofreciendo aislamiento pero posiblemente requiriendo que los usuarios inicien sesión de nuevo.	- Se ejecuta dentro del proceso de Chrome: Al ser parte de Chrome, las Custom Tabs se ejecutan en el mismo proceso y tienen las mismas actualizaciones de seguridad y características que Chrome. - Jar de cookies y modelo de permisos compartidos: Asegura que los usuarios no tengan que volver a iniciar sesión en los sitios o volver a otorgar permisos. - Configuración y preferencias de Chrome: Utiliza la configuración y las preferencias de Chrome.
Vulnerabilidades	- Callbacks para robar credenciales: Las vulnerabilidades potenciales incluyen que a veces se requiere JavaScript, lo que abre la puerta para que otras aplicaciones ejecuten código malicioso, como registrar callbacks que intentan interceptar nombres de usuario y contraseñas. - Phishing: Además, una aplicación maliciosa podría abrir otra página web que imite el flujo de Link en un intento de phishing.	- Navegación Segura de Google: Emplea la Navegación Segura de Google para proteger tanto al usuario como al dispositivo de sitios peligrosos. - Decoración segura del navegador: Asegura que el usuario siempre vea la URL exacta con la que está interactuando y pueda ver la información del certificado del sitio web, reduciendo el riesgo de phishing. Además, las pestañas personalizadas no permiten la inyección de JavaScript.
Otros	- Google prohibió los WebViews para que los usuarios inicien sesión en cuentas de Google

5. Recomendación para la implementación de passkeys en aplicaciones nativas#

Nuestros clientes nos preguntan continuamente cómo se deben implementar las passkeys en las aplicaciones nativas. En gran medida, esos clientes se pueden dividir en diferentes grupos:

Grupo A:

Clientes que comienzan a construir su aplicación nativa desde cero y pueden usar directamente nuestra autenticación sin contraseña (no existen contraseñas heredadas).

Grupo B:

Clientes con usuarios existentes y una solución de autenticación existente. A menudo también tienen una aplicación web existente que también necesita agregar passkeys a su proceso de autenticación. Aquí muchas empresas deciden seguir un proceso de dos pasos:

Agregar passkeys a tu flujo de autenticación de WebView existente (así es como Google y GitHub lo implementaron en sus aplicaciones nativas)
Agregar passkeys a través de una implementación nativa encima. Esta implementación nativa de passkeys comprueba antes del antiguo WebView (p. ej., para inicios de sesión sociales y contraseñas) si el usuario puede iniciar sesión con una passkey (así es como KAYAK lo implementó en su aplicación nativa).

Determina tu grupo

Para proporcionar a tus usuarios la mejor implementación de passkeys en una aplicación nativa, necesitas decidir a qué grupo perteneces, basándote en tu configuración técnica actual y cómo quieres impulsar las passkeys (esta pregunta es relevante para las empresas del grupo B).

Recomendación para el Grupo A: Implementación nativa

Si estás construyendo una aplicación completamente nueva (grupo A), recomendamos optar por una implementación nativa de passkeys y volverse completamente sin contraseña de inmediato (por lo que no se utiliza ningún tipo de WebView). Por favor, utiliza los SDKs y APIs nativos para iOS y Android (p. ej., a través del paquete de passkeys para Flutter). Por favor, lee también este artículo sobre los ID de Relying Party.

Recomendación para el Grupo B: Primero WebView, luego implementación nativa

Si no puedes implementar passkeys de forma nativa hoy por cualquier motivo (grupo B), puedes comenzar con una implementación de WebView y luego pasar en el futuro a una implementación nativa de passkeys (esto funciona mediante la creación de archivos de asociación, como apple-app-site-association para aplicaciones de iOS y assetlinks.json para aplicaciones de Android). Las razones para optar por una implementación de WebView pueden incluir:

Ya ofreces autenticación basada en OAuth2 y quieres seguir ofreciéndola a tus usuarios (OAuth2 no funciona de forma nativa, consulta el estándar aquí)
Quieres ofrecer autenticación con passkeys en la misma ventana / pantalla donde ofreces tus otros métodos de autenticación (p. ej., contraseñas, inicios de sesión sociales, OAuth2)

Esta es la forma en que Google o GitHub han implementado la autenticación con passkeys en sus aplicaciones nativas actualmente. Por favor, consulta la recomendación a continuación para configurar los WebViews correctamente para la autenticación con passkeys. Sin embargo, recomendamos considerar una implementación nativa de passkeys como lo hizo KAYAK y comenzar directamente con el paso 2.

Si perteneces al grupo B y no puedes implementar passkeys de forma nativa, nuestra recomendación se inclina hacia la utilización de SFAuthenticationSession / ASWebAuthenticationSession para iOS y Chrome Custom Tabs para Android (de lo contrario, las passkeys no funcionarán de todos modos).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

A continuación, exponemos las razones de esta recomendación:

5.1 Cookies y datos compartidos con el navegador#

SFAuthenticationSession / ASWebAuthenticationSession comparten cookies y datos de sitios web con Safari, proporcionando una experiencia de usuario fluida durante los procesos de autenticación. Lo mismo se aplica a las Chrome Custom Tabs en Android.

Los usuarios se benefician de sus contraseñas guardadas, datos de autocompletar y otra información almacenada en el navegador, lo que hace que el proceso de autenticación sea más fluido y rápido.

5.2 Seguridad mejorada#

SFAuthenticationSession / ASWebAuthenticationSession en iOS y Chrome Custom Tabs en Android proporcionan un espacio seguro y aislado para la autenticación del usuario, asegurando que las credenciales sensibles del usuario estén salvaguardadas y no se compartan inadvertidamente con la aplicación u otros sitios web.

Se adhieren a los estrictos protocolos de seguridad de Apple y Google, asegurando que los datos del usuario se manejen de forma segura y se mantenga la privacidad.

Además, esta elección de diseño se beneficia de las continuas actualizaciones y mejoras de seguridad de Safari y Chrome, asegurando que se adhiera a los últimos estándares y protocolos de seguridad.

5.3 Experiencia de usuario#

SFAuthenticationSession / ASWebAuthenticationSession en iOS y Chrome Custom Tabs en Android proporcionan una interfaz de usuario consistente y familiar, ya que los usuarios están acostumbrados a la experiencia de usuario del navegador. Además, se aplican la configuración y las preferencias de usuario de Safari y Chrome.

Proporciona una transición fluida entre el contenido de la aplicación y el contenido web, asegurando que los usuarios no se vean sorprendidos por el cambio entre interfaces.

5.4 Rendimiento#

Chrome Custom Tabs aprovechan el rendimiento de Chrome, asegurando una experiencia de usuario fluida y receptiva, lo cual es particularmente crucial durante los procesos de autenticación para evitar la frustración o el abandono del usuario.

El rendimiento de CCT es a menudo superior a las opciones de WebView de Android (lo mismo ocurre con SFAuthenticationSession / ASWebAuthenticationSession en iOS), asegurando que el contenido web y los flujos de autenticación se manejen de manera rápida y fluida.

Consulta también esta comparación de Google para sentir las diferencias de rendimiento entre Chrome Custom Tabs, Android WebView y el navegador Chrome estándar.

5.5 Dedicado a los flujos de autenticación#

SFAuthenticationSession / ASWebAuthenticationSession está diseñado específicamente para manejar flujos de autenticación basados en OAuth / OpenID Connect, asegurando un proceso optimizado y seguro para estos protocolos de autenticación ampliamente utilizados. También es la forma recomendada para la autenticación con WebAuthn / passkeys.

En Android, no hay una clase dedicada para los flujos de autenticación, pero se puede implementar un comportamiento similar con Chrome Custom Tabs y Android App Links.

Además, esperamos que más aplicaciones introduzcan passkeys como TikTok, simplemente recogiéndolas cuando el usuario está autenticado. Esto se puede hacer de forma nativa (la implementación de TikTok) o a través de una implementación de WebView. Un enfoque adecuado es activar la IU Condicional de forma nativa. Si no funciona, se muestra la implementación de WebView.

6. Conclusión#

En el panorama moderno de la autenticación digital, la implementación de passkeys a través de WebView en aplicaciones nativas emerge como un faro de práctica segura y amigable para el usuario. Si bien el camino para elegir el WebView óptimo puede ser intrincado, es fundamental alinear las elecciones tecnológicas con la experiencia del usuario y la seguridad.