Passkeys en aplicaciones web: cómo implantar un acceso sin contraseñas

14.08.2026 · Lectura: 7–9 min

Las passkeys permiten iniciar sesión en una aplicación web sin escribir una contraseña: el usuario confirma el acceso con el desbloqueo de su dispositivo y el servidor verifica una firma criptográfica vinculada al dominio. Para una empresa, la implantación sensata no consiste en activar un botón y retirar todas las contraseñas el mismo día. Requiere planificar el alta, la convivencia con el acceso actual, la recuperación de cuenta y las pruebas en dispositivos reales.

Bien desplegadas, las passkeys reducen la exposición al phishing y evitan que el servidor tenga que validar un secreto compartido que el usuario pueda reutilizar o revelar. Pero no sustituyen la autorización, la seguridad de las sesiones, la protección del correo ni el control de acciones sensibles. Son una pieza del sistema de identidad, no una solución completa por sí sola.

Qué cambia cuando una web usa passkeys

Las passkeys se apoyan en WebAuthn, el estándar del W3C para usar credenciales de clave pública en la web. Durante el registro, el navegador o el sistema operativo pide al autenticador que cree un par de claves. La clave privada permanece protegida por el dispositivo o el proveedor de credenciales; la aplicación conserva la clave pública y los datos necesarios para identificar esa credencial.

Al iniciar sesión, el servidor envía un reto único. El usuario confirma la operación con el mecanismo local de su dispositivo —por ejemplo, biometría, PIN o patrón— y el autenticador firma el reto para el dominio correspondiente. El servidor comprueba la firma y el contexto. La biometría no se entrega a la web: sirve para desbloquear localmente el uso de la credencial.

Esta relación con el dominio es importante. Una página falsa no puede pedir una firma válida para el dominio legítimo. Aun así, la aplicación debe validar correctamente el origen, el identificador de la parte dependiente, el reto, el tipo de operación y los indicadores devueltos por WebAuthn. Una implementación incompleta puede perder parte de la protección que ofrece el estándar.

En qué proyectos tiene más sentido empezar

Un buen candidato es un portal de clientes, una aplicación web interna, un área de proveedores o una tienda con cuentas recurrentes. Cuanto más frecuentes sean los accesos y mayor sea el coste de restablecer contraseñas, más valor puede aportar un método rápido y resistente al phishing. También puede ayudar cuando el negocio quiere elevar la protección de administradores o de personas con permisos sensibles.

No todos los usuarios ni todos los recorridos tienen que migrar a la vez. Un comercio con muchas compras como invitado quizá obtenga más impacto empezando por el panel de administración. Una aplicación B2B puede ofrecer passkeys primero a un grupo piloto y mantener temporalmente el método anterior. La prioridad debe salir del riesgo, del volumen de accesos y de la capacidad real de soporte.

Antes de programar, inventaría identidad, dominios y dispositivos

El diseño técnico comienza con el mapa actual de autenticación. Hay que identificar quién crea las cuentas, qué dominios y subdominios intervienen, dónde se guardan las sesiones, qué proveedores externos participan y qué acciones requieren una nueva confirmación. También conviene separar autenticación —demostrar quién accede— de autorización —decidir qué puede hacer después—.

El inventario debería responder, como mínimo, a estas preguntas:

• ¿El acceso se realiza siempre por HTTPS y qué origen usará WebAuthn?
• ¿Una misma cuenta puede tener varias credenciales y cómo se mostrarán al usuario?
• ¿Se admitirán passkeys sincronizadas, llaves físicas o ambas opciones?
• ¿Qué navegadores, móviles y ordenadores utiliza realmente la audiencia?
• ¿Cómo se revoca una credencial perdida sin bloquear todas las demás?
• ¿Qué registros necesita soporte para investigar un acceso sin almacenar datos innecesarios?
• ¿Qué acciones críticas exigen una autenticación reciente?

MDN recomienda usar un desafío generado de forma segura y verificarlo en el servidor. Además, la credencial debe quedar asociada a la cuenta correcta y no puede aceptarse dos veces una respuesta pensada para una operación anterior. La lógica sensible pertenece al servidor; no debe confiarse únicamente al JavaScript del navegador.

Una migración gradual evita crear un nuevo bloqueo

La primera fase suele consistir en añadir una passkey desde una sesión ya autenticada. Antes del alta conviene volver a comprobar la identidad cuando el riesgo lo justifique y explicar con claridad qué dispositivo o proveedor guardará la credencial. Después, el usuario debería poder asignarle un nombre comprensible, revisar sus credenciales y eliminar una que ya no controle.

Durante la convivencia, el inicio de sesión puede ofrecer la passkey como opción preferente sin ocultar de golpe el acceso existente. Los navegadores compatibles permiten integrar credenciales detectables en el selector de autocompletado mediante la mediación condicional. Esto reduce pasos, pero exige probar el formulario cuando no existe ninguna passkey, cuando el navegador no admite la función o cuando la persona decide usar otro método.

Retirar las contraseñas solo debería plantearse después de medir la adopción, los fallos y las solicitudes de soporte. También hay que revisar cuentas creadas por invitación, usuarios compartidos —que conviene sustituir por identidades individuales—, integraciones antiguas y procesos automáticos que quizá no utilicen un navegador interactivo.

La recuperación es parte de la autenticación, no una pantalla secundaria

Una passkey resistente al phishing pierde valor si la recuperación permite tomar una cuenta con una pregunta fácil o un correo insuficientemente protegido. OWASP recomienda tratar los factores alternativos y el restablecimiento con un nivel de seguridad acorde con la cuenta. El procedimiento debe contemplar pérdida del móvil, cambio de empresa, ausencia de un dispositivo sincronizado y errores de soporte.

Una estrategia práctica combina varias medidas según el riesgo:

1. permitir registrar más de una passkey, por ejemplo en dos dispositivos o con una llave física;
2. mostrar y revocar credenciales desde una sesión confiable;
3. avisar por un canal ya verificado cuando se añade o elimina una credencial;
4. definir un proceso de recuperación con controles adicionales y tiempos de espera cuando proceda;
5. pedir nueva autenticación antes de cambiar correo, permisos, datos de pago o métodos de acceso;
6. registrar los eventos relevantes para poder investigar abusos sin exponer claves ni datos biométricos.

El soporte humano también necesita límites: qué evidencias puede solicitar, quién aprueba una excepción y cómo se evita que una conversación urgente se convierta en una puerta trasera. Ese guion debe ensayarse antes de que llegue el primer caso real.

Qué probar antes de abrirlo a toda la base de usuarios

Una prueba de escritorio no cubre un sistema de passkeys. Hace falta una matriz con los navegadores y sistemas más utilizados, móviles y ordenadores, credenciales sincronizadas y ligadas a un dispositivo, navegación privada cuando sea relevante y cambios entre plataformas. Hay que incluir tanto el camino correcto como los abandonos y errores.

• alta, inicio de sesión, renombrado y revocación de una credencial;
• cuenta con una, varias o ninguna passkey disponible;
• móvil perdido, dispositivo nuevo y proveedor de credenciales no accesible;
• cancelación del diálogo, reto caducado y respuesta repetida;
• cambio de dominio, subdominio o entorno de pruebas;
• lectores de pantalla, uso con teclado y mensajes de error comprensibles;
• cierre de sesiones activas y reautenticación de operaciones sensibles.

Las métricas iniciales deberían distinguir invitaciones, altas completadas, accesos correctos, fallos por etapa, recuperaciones y contactos con soporte. No basta con medir que el botón se pulsa: hay que saber si la persona vuelve a entrar días después y si el método alternativo está creando un riesgo o una barrera.

Checklist para decidir el siguiente paso

Antes de aprobar el desarrollo, confirma que existe un propietario del sistema de identidad, una audiencia prioritaria, un inventario de dominios y métodos actuales, un plan de convivencia, al menos una vía de recuperación proporcionada al riesgo y una matriz de pruebas. Define también qué resultado justificaría ampliar el despliegue y qué señal obligaría a detenerlo.

En un proyecto de desarrollo web a medida, estas decisiones deberían entrar en la arquitectura y en los recorridos de usuario desde el principio. Si la aplicación ya está en funcionamiento, la implantación necesita coordinarse con el mantenimiento técnico y con los responsables de identidad y soporte. Para valorar el caso concreto, puede iniciarse la conversación desde contacto.

Preguntas frecuentes sobre passkeys y VOWE

¿Puede VOWE añadir passkeys a una aplicación web existente?

Sí. Dentro del desarrollo web a medida y el soporte técnico, VOWE puede revisar la autenticación actual, diseñar la convivencia con los métodos existentes e implantar WebAuthn por fases. El alcance depende de la arquitectura, el proveedor de identidad, los dominios, los navegadores de la audiencia y los accesos técnicos disponibles.

¿Hay que eliminar las contraseñas desde el primer día?

No. Normalmente conviene empezar con un grupo piloto, ofrecer el alta de passkeys desde una sesión verificada y mantener temporalmente un método alternativo. La retirada de contraseñas debe decidirse después de medir adopción, errores, recuperación y carga de soporte, sin dejar una vía alternativa más débil.

¿Qué necesita VOWE para valorar la implantación?

Para una primera valoración hacen falta la URL y la tecnología de la aplicación, los dominios de acceso, el sistema de identidad actual, los tipos de usuario, los dispositivos habituales, las acciones sensibles y el proceso de recuperación existente. No es necesario enviar contraseñas ni secretos mediante el formulario de contacto.

Fuentes y límites de esta guía

Este artículo sintetiza la especificación Web Authentication Level 3 del W3C, la documentación de MDN sobre passkeys y su referencia de la Web Authentication API, junto con las recomendaciones de las guías de autenticación y autenticación multifactor de OWASP. La arquitectura y la recuperación deben adaptarse al riesgo y a la tecnología de cada servicio; esta guía no sustituye una auditoría de seguridad ni asesoramiento jurídico individual.