Novedades de claves de acceso

Hola, soy Andrew, ingeniero del equipo de Authentication Experience. Hacemos que iniciar sesión sea sencillo, rápido y seguro.

Muchos problemas de inicio de sesión y seguridad de la cuenta se deben a las contraseñas. Para erradicar estos problemas, la industria propone reemplazar las contraseñas por llaves de acceso en las cuentas en línea. Las llaves de acceso resuelven de raíz los problemas de seguridad y usabilidad de las contraseñas, incluido el phishing, y ofrecen una agradable experiencia de inicio de sesión.

Este video está a cargo del equipo que hace que esto sea posible. Trabajamos en pos de ese gran objetivo de reemplazar las contraseñas por llaves de acceso.

Las llaves de acceso son la solución: toda la industria debe migrar a una autenticación protegida por factores imposibles de suplantar. Esto supone una serie de pasos. Antes de las llaves de acceso, muchas cuentas usaban factores suplantables, como contraseñas o códigos de uso único enviados por SMS o correo.

El primer paso es agregar un método de acceso imposible de suplantar, como las llaves de acceso. Gran parte de la industria está en ese paso. El objetivo es que ninguna cuenta use factores suplantables, y las llaves de acceso son la solución para lograrlo. El panorama general es muy positivo, ya que cada vez más usuarios adoptan estas llaves y más servicios las admiten. Según un estudio de 2025 de FIDO Alliance, ente que estandariza las llaves de acceso, el 69% de los encuestados tiene al menos una llave.

Según Google, quienes usan llaves de acceso tienen cuatro veces más éxito para iniciar sesión en sus cuentas que quienes usan contraseñas. TikTok registró un notable éxito del 97% en los inicios de sesión con llaves de acceso. Este éxito con las llaves de acceso se repite en toda la industria y es inaudito con las contraseñas.

La creciente y exitosa adopción refleja un avance claro hacia las llaves de acceso. iOS, iPadOS, macOS y visionOS 26 se basan en llaves de acceso y nuevas mejoras que facilitan aún más su descubrimiento, creación y uso en tus apps y sitios web. Veamos cinco novedades clave. Primero, la nueva API de creación de cuentas. Es la forma más rápida y fácil de crear una nueva cuenta, y usa una llave de acceso desde el principio.

Segundo, cómo mantener al día estas llaves y sincronizar cambios en la cuenta con administradores de credenciales.

Tercero, la actualización automática a llaves de acceso en cuentas existentes con contraseña. Cuarto, puntos finales para administrar llaves de acceso y mostrar en administradores de credenciales que tu servicio las admite.

Quinto, importación y exportación de llaves de acceso, un gran avance que ofrece a los usuarios más flexibilidad y control sobre ellas.

Primero, la nueva API de creación de cuentas. A diferencia de los registros por contraseña, configurar una llave de acceso es rápido y sencillo. Es decir, no requiere esfuerzo. Las llaves de acceso no suponen crear una contraseña compleja ni recordarla.

Hacen que el inicio de sesión sea rápido y sencillo, y no son suplantables. Con la API de creación de cuentas y las últimas versiones del SO, los registros son una experiencia agradable, rápida y más segura.

Veámoslo en mi iPhone con la app de demostración Shiny. Te muestra una foto linda al día.

Como con toda app nueva, el primer paso es registrarse. Esta es la forma tradicional, previa a la API de creación de cuentas. Primero, crearé una nueva cuenta con mi correo electrónico.

Debo llenar un formulario, empezando por el correo electrónico. Por suerte, el autocompletado me ayuda. Listo lo del correo. Ahora, mi nombre y apellido.

Y la temida contraseña, por supuesto. Seguiré la práctica recomendada y usaré la contraseña segura automática.

Por último, tocaré Continuar y ya estoy registrado. Ahí está la foto linda. ¡Adorable! Ahora repetiré todo tras adoptar la API de creación de cuentas. De manera similar, crearé una nueva cuenta con mi correo.

Pero, en vez del formulario de varios pasos, el sistema muestra exactamente lo que Shiny solicita: mi nombre, mi correo electrónico y una llave de acceso que se guardará en la app Contraseñas. Y lo mejor es que viene precargado. Este es el nuevo flujo optimizado de la API de creación de cuentas. Los datos compartidos pueden editarse. Si toco un campo, puedo alternar entre las sugerencias de un selector o ingresar algo manualmente. Los valores predeterminados están bien. Tocaré Continuar, Face ID me autenticará y listo. Estoy registrado y en Shiny. Mucho más rápido, simple y seguro.

Iniciar sesión es igual de sencillo.

Si abro Shiny por primera vez en mi iPad, se me solicitará iniciar sesión al instante porque la app está configurada para verificar las credenciales existentes al iniciarse. La llave de acceso que creé está disponible en todos mis dispositivos. Toco Continuar, Face ID y listo. ¡Así de fácil! Esta experiencia se ofrece en apps de iOS, iPadOS, macOS y visionOS, y funciona con la app Contraseñas y administradores de credenciales de terceros.

Veamos la implementación que hace posible esa experiencia de registro.

Esta función muestra los pasos clave para crear una cuenta. Primero, inicia el nuevo proveedor de creación de cuentas. Luego, úsalo para crear una solicitud de registro de llave de acceso. En este método, se especifican los detalles clave. El primer parámetro es acceptedContactIdentifiers, que indica al sistema qué tipo de identificadores de cuenta admite tu app. Tu app recibe solo el identificador elegido para crear la cuenta, usado como etiqueta de nombre de usuario de la llave de acceso. ShouldRequestName indica si se debe solicitar el nombre del usuario. Establécelo como verdadero si es necesario para crear la cuenta. Los próximos 3 atañen a la llave de acceso que se creará. Coinciden con el registro de llave de acceso estándar, así que brinda los mismos datos.

La parte que registra la llave de acceso (generalmente un dominio), un desafío único para firmar con la llave de acceso creada (obtenido de tu servidor) y el ID de usuario (identificador único y estable que creas para la cuenta). Luego, obtén una instancia de ASAuthorizationController. En SwiftUI, puedes obtenerla con el contenedor de propiedades Environment. Luego, ejecuta la solicitud. Cuando alguien complete con éxito el flujo de registro, recibirás un ASAuthorizationResult. Extrae su contenido y verás un identificador de contacto, el nombre si se solicita y un objeto de llave de acceso. Crea una cuenta nueva en tu servidor y accede con esos datos.

Eso es, en esencia, la adopción. Si algo sale mal, el método perform arrojará un error que puedes manejar para que la experiencia sea excelente de todos modos. Además de los errores comunes de AuthenticationServices, hay 3 errores que manejar de suma importancia para esta API. El primero, deviceNotConfiguredForPasskeyCreation, indica que el dispositivo no está preparado para crear una llave de acceso, p. ej., si no tiene un código de acceso. Si sabes que alguien no puede crear una llave de acceso, puedes mostrar tu formulario de registro estándar. Al tocar para usar el correo electrónico o número de teléfono, el error se maneja con un formulario de registro personalizado. El segundo error es canceled. Este error se produce si alguien descarta la hoja de registro sin completarla. Puedes abordarlo con tu formulario de registro estándar. Cuando se descarta la hoja del sistema, el error se maneja con un formulario de registro personalizado. El último es preferSignInWithApple. Solo recibirás este error si tu app admite Iniciar sesión con Apple. Está diseñado para evitar las cuentas duplicadas por error. Si alguien inicia el flujo de creación de cuenta, pero ya creó una con Iniciar sesión con Apple, el sistema se lo recordará con una alerta como esta. Se le da la opción de acceder a su cuenta existente de Iniciar sesión con Apple o de crear una nueva. Si usa la cuenta existente, se arroja este error. Por eso, al recibir este error, lo mejor es iniciar una solicitud de Iniciar sesión con Apple, que muestra la hoja de esa función. Esto respeta su elección y le permite acceder a su cuenta existente sin toques adicionales. Eso es todo sobre los errores. Otra práctica recomendada es ofrecer cualquier cuenta existente tras abrir la app para ayudar a las personas a iniciar sesión. Como en el ejemplo del iPad, cuando se me pidió que iniciara sesión con mi llave de acceso sin que tuviera que pensar si tenía una cuenta o cómo había ingresado la última vez. Esto pasó porque Shiny usó una solicitud de inicio de sesión combinada que priorizaba las credenciales disponibles. Si alguien tiene credenciales en su dispositivo (una llave de acceso o contraseña de cualquier administrador de credenciales o una cuenta que usa Iniciar sesión con Apple), se le ofrecerá iniciar sesión. Si no hay credenciales disponibles, no se muestra ninguna IU, o sea no se interrumpe la pantalla de inicio de sesión. Obtén más información en el video “Meet Passkeys” de la WWDC22.

Esa es la API de creación de cuentas, una nueva función que hace que registrarse sea fácil y seguro.

Tras crear una cuenta, si la llave de acceso se mantiene precisa en los administradores de credenciales, la experiencia será fluida. Esto me lleva al segundo tema: mantener al día las llaves de acceso. Las cuentas no son estáticas. La gente cambia sus datos (nombre de usuario, correo electrónico, etc.) y revoca llaves de acceso. Si los administradores de credenciales muestran datos desactualizados, puede causar confusión y entorpecer o impedir el inicio de sesión en tu servicio. Un nuevo conjunto de API permite a tu app o sitio web informar a los administradores de credenciales sobre cambios en una cuenta. Estas API garantizan datos precisos e inicios de sesión rápidos, seguros y que simplemente funcionan.

Veamos cómo funciona en Shiny. Digamos que me acabo de graduar y quiero cambiar mi antigua cuenta de correo electrónico de estudiante a una personal.

En la configuración de la app, toco el correo e ingreso el nuevo.

Luego, guardo.

Enseguida, mi administrador de credenciales, la app Contraseñas, me envía una notificación del cambio.

Si la toco, Contraseñas me autentica y, luego, muestra los detalles de la cuenta.

El nombre de usuario refleja el nuevo correo electrónico personal. Los datos del administrador de credenciales y del backend coinciden. Genial, ¿no? Esto es posible gracias a una nueva API para apps y la Web. En apps, la nueva clase ASCredentialUpdater permite informar ciertos cambios en las credenciales. En la Web, el estándar WebAuthn, compatible con Safari 19 y otros navegadores, ofrece métodos similares.

La primera señal es para los cambios de nombre de usuario. Como en el ejemplo, si alguien actualiza su usuario, dirección de correo o cualquier etiqueta de la cuenta, informa al administrador de credenciales con el método reportPublicKeyCredentialUpdate. Esto garantiza que la etiqueta que se muestra en el inicio de sesión sea actual y evita confusiones. Los nombres de usuario en las llaves de acceso son etiquetas locales. No se envían al servidor durante la autenticación.

En la Web, usa el método signalCurrentUserDetails en PublicKeyCredential para lograr lo mismo.

Ahora, revocaciones de llaves de acceso. Hay apps y sitios web con páginas para administrar llaves de acceso que permiten revocar una llave individual o crear una nueva. Para cada revocación, llama al método reportAllAcceptedPublicKeyCredentials, especificando los ID de credenciales que siguen siendo válidos. Así, los administradores de credenciales eliminarán cualquier llave de acceso que no esté en el conjunto proporcionado. Esto evita que se ofrezca una llave de acceso no válida en el inicio de sesión. Puedes llamar a ese método para verificar el estado de una cuenta. Si hubo un cambio, esto ayuda a mantener al tanto a los administradores de credenciales.

Puedes hacer lo mismo en la Web con el método signalAllAcceptedCredentials.

Al final, las cuentas más seguras son las que no tienen ninguna contraseña. Con la API de creación de cuentas, las cuentas nunca llevan contraseña, o sea, son seguras desde el día uno.

Puedes informar a los administradores de credenciales si una cuenta actual ya no necesita una contraseña. La API de reportUnusedPasswordCredential indica que una cuenta terminó de adoptar una llave de acceso y ya no tiene contraseña.

Los administradores de credenciales pueden participar en el manejo de estas señales. Hay nuevas API para escuchar estas señales de cambio y mantener al día las credenciales administradas. Hay más detalles en la documentación para desarrolladores sobre métodos de informe en ASCredentialProviderViewController. Estas API mantienen la precisión de las credenciales. Veamos cómo fomentar la adopción de llaves de acceso, en especial entre quienes aún usan contraseñas. La actualización automática permite agregar llaves de acceso fácilmente a cuentas que usan contraseñas. Tu app o sitio web puede crear una fácilmente tras un inicio de sesión con contraseña. Veamos cómo. En Shiny, imagina que aún uso la contraseña y quiero iniciar sesión. Completo mi usuario y contraseña, toco Iniciar sesión y listo. Veamos qué pasa tras adoptar la actualización automática a llaves de acceso. Recibo una notificación de que se creó una llave. Sin pantallas promocionales ni interrupciones, solo una transición fluida hacia una experiencia más simple y segura. Cabe notar que la contraseña que acabo de usar aún funciona. Solo se agregó la llave de acceso como forma segura de ingresar. Así se ve en código esa actualización automática. Si alguien inicia sesión con contraseña, puedes acceder a los detalles de su cuenta. Verifica si la cuenta ya tiene una llave de acceso. Si no es así, crea una solicitud de registro de llave de acceso como al crear una llave. Aplica el estilo condicional para activar la actualización automática a llaves de acceso. Así, al enviarse la solicitud, el sistema y el administrador de credenciales hacen verificaciones en segundo plano. Verifican si hay un administrador de credenciales, si se acaba de usar la contraseña de la cuenta y si el dispositivo admite llaves de acceso. Si se cumplen todas las condiciones previas, el sistema crea una llave de acceso y muestra una notificación, y tu app recibe ese objeto de llave para guardarla, todo sin interrumpir ni demorar al usuario. Si alguna condición no se cumple, la llamada falla en silencio. No aparece ninguna IU ni se aplican manejos de errores específicos. La app buscará actualizar los inicios de sesión con contraseña cuando el usuario no tenga una llave de acceso.

Hay una API web equivalente. Obtén más información sobre la actualización automática a llaves de acceso en el video “Streamline sign-in with passkey upgrades and credential managers” de la WWDC24. La actualización automática ofrece esa experiencia ideal.

Si usas la URL conocida para los puntos finales de administración de llaves de acceso, los administradores podrán dirigir directamente a tus páginas de administración. Es ideal para mostrar que adoptaste las llaves de acceso. Veamos cómo. En la app Contraseñas, veo que aún se usa una contraseña en Shiny. Esta nueva sección me indica que hay una actualización a llaves de acceso. Si toco “Agregar llave de acceso”, se abre directamente el sitio web para registrar la llave de acceso.

Este estándar crea un enlace directo entre los administradores de credenciales y tus páginas de registro de llaves. Permite ejecutar la actualización directamente desde el administrador de credenciales. Como se basa en un estándar, funciona en todos los administradores participantes.

Esto requiere una respuesta JSON en la ruta “.well-known/passkey-endpoints” de tu servidor. La respuesta debe provenir de esta ruta, sin redireccionamientos.

Sírvela con el código de estado “200 OK” y el encabezado “Content-Type: application/json”.

El contenido es un diccionario JSON que apunta a páginas relevantes de tu sitio web.

“Enroll” es la URL para agregar la llave de acceso a una cuenta. Allí dirige al botón Agregar llave de acceso de la app Contraseñas. “Manage” es la URL para administrar llaves de acceso existentes, similar a una página de cambio de contraseña. Allí se pueden revocar llaves existentes o agregar una nueva.

Los campos son opcionales, pero es mejor incluir ambos. Es importante que estas URL manejen correctamente a las personas que llegan sin una sesión autenticada. Si se debe iniciar sesión, primero autentica al usuario y, luego, dirígelo a la URL solicitada.

Asegúrate de que esta página sea accesible y esté disponible para todos. No solo los navegadores la solicitarán, sino también apps como administradores de credenciales.

Implementar la URL conocida para puntos finales de administración de llaves de acceso ayuda a que los administradores de credenciales promuevan la adopción en tu servicio.

Veamos la importación y exportación de llaves de acceso.

Las personas son dueñas de sus credenciales y deberían poder administrarlas donde quieran. Tengo una buena noticia: las llaves de acceso ahora se pueden transferir de forma segura entre apps de administración participantes en iOS, iPadOS, macOS y visionOS 26. Esto da a las personas más control sobre sus datos y la elección de qué administrador usar.

Este nuevo proceso es más seguro que los métodos tradicionales de exportación de credenciales, que consisten en exportar un archivo CSV o JSON sin cifrar y, luego, importarlo manualmente a otra app. El proceso de transferencia lo inicia el usuario, ocurre directamente entre las apps participantes y está protegido por autenticación local, como Face ID. Esta transferencia usa un esquema de datos creado en colaboración con los miembros de FIDO Alliance, que estandariza el formato de datos para llaves de acceso, contraseñas, códigos de verificación, etc. El sistema ofrece un mecanismo seguro para mover los datos entre apps. No se crean archivos inseguros en el disco, evitando las filtraciones de credenciales por exportación. Es una forma moderna y segura de transferir credenciales.

No hace falta adaptar las apps ni los sitios web para admitir la transferencia de credenciales, ya que esta ocurre entre los administradores. Las llaves de acceso existentes permanecen igual y siguen funcionando. Para apps de administración de credenciales que desean admitir la transferencia, consulta la documentación sobre ASCredentialExportManager y ASCredentialImportManager.

Las llaves de acceso siguen mejorando para ofrecer experiencias más simples y seguras. Las nuevas versiones de SO facilitan su creación, uso y descubrimiento. Estamos juntos en este camino hacia un futuro sin contraseñas y adoptar estas soluciones es clave para hacerlo realidad. Veamos los pasos que debes seguir para ofrecer la mejor experiencia de autenticación. Usa la API de creación de cuentas para una adopción rápida y segura. Mantén las llaves al día con las API de señales, que informan a los administradores sobre cambios en la cuenta, como nuevos nombres de usuario o revocación de llaves. Activa la actualización automática para dejar atrás sin complicaciones las contraseñas. Por último, promueve esas actualizaciones en administradores de credenciales publicando los puntos finales de administración de tu sitio web. Eso es todo. Gracias por ver este video.