Prompt y contexto aplicable
El producto ya admite el inicio de sesión con usuario/contraseña y conditional get para el inicio de sesión con passkeys. Quieres utilizar WebAuthn Level 3 conditional create tras un inicio de sesión de alta confianza, sugiriendo una passkey sin interrumpir el flujo. Explica la detección de capacidades del navegador, las compuertas de creación, la validación en el servidor, los límites de privacidad y el rollback.
Esto se enfoca en la plataforma Web y la UX de autenticación. Que la API sea compatible con el navegador no significa que el dispositivo tenga un autenticador utilizable; la creación aún requiere el consentimiento del usuario y la verificación del servidor.
Qué evalúa el entrevistador
- Si distingues entre conditional create, conditional get y la creación explícita mediante un botón.
- Si conectas la capacidad, las políticas, el estado de la cuenta y la sincronización multidispositivo en compuertas claras.
- Si previenes credenciales duplicadas, vinculaciones erróneas de cuentas, filtraciones sobre la existencia de credenciales y bloqueos en el inicio de sesión con contraseña.
- Si puedes realizar un despliegue canary y retirar la funcionalidad en lugar de habilitar una nueva API en todas partes.
Una respuesta sólida trata conditional create como una mejora progresiva: los intentos no admitidos, cancelados o expirados dejan el flujo principal sin cambios, mientras que el servidor sigue verificando el challenge, el origin, el RP ID y la vinculación con la cuenta.
Preguntas aclaratorias antes de responder
- ¿El objetivo es cada usuario autenticado o solo usuarios con correo electrónico verificado, MFA o una reautenticación reciente de alto riesgo?
- ¿Se permiten passkeys sincronizadas multidispositivo? Eso cambia los requisitos de recuperación y revocación.
- ¿Puede la página tener ya una solicitud
credentials.create()pendiente? Las solicitudes simultáneas hacen que las solicitudes de interacción sean impredecibles. - Cuando conditional create no esté disponible, ¿se debe mostrar un botón explícito de “Crear una passkey” u ocultar la funcionalidad?
Estructura de respuesta de 30 segundos
“Detectaría la capacidad de conditional-create y luego combinaría el estado de la cuenta, la solidez de la autenticación reciente y un feature flag en el servidor antes de intentarlo. El cliente inicia como máximo una solicitud en un momento explícito aprobado por el usuario y cancela duplicados con AbortController; los intentos no admitidos, cancelados o con tiempo de espera agotado regresan al flujo original. El servidor vincula un challenge de un solo uso al usuario, origin, RP ID y vencimiento, y almacena la credencial solo después de la verificación. Durante el canary rastrearía el éxito en la creación, cancelaciones, credenciales duplicadas, fallback a contraseña y tickets de recuperación. Un incidente desactiva el flag; las credenciales existentes aún se pueden usar o revocar por separado.”
Respuesta detallada paso a paso
1. Separar las dos interacciones condicionales
Conditional get permite al usuario elegir una passkey existente al ingresar su cuenta; conditional create sugiere registrar una nueva credencial dentro del contexto del formulario. Ambas dependen de la capacidad del navegador y del autenticador, por lo que verificar únicamente el objeto PublicKeyCredential es insuficiente.
La detección de capacidades decide si se intenta, no si se autoriza. El servidor aún debe vincular el registro al usuario actualmente autenticado y registrar el origen de la creación y la versión de la política.
2. Definir compuertas de creación
Exigir todo lo siguiente: que el navegador reporte capacidad de conditional-create; que el usuario haya completado recientemente una autenticación suficiente; que la cuenta no esté en proceso de recuperación, fusión o cambio de alto riesgo; y que un flag del servidor habilite el tenant y el segmento de tráfico. En un dispositivo nuevo, explica el beneficio y permite que el usuario continúe en lugar de crear la credencial al cargar la página.
3. Evitar duplicados y condiciones de carrera
Permite una sola solicitud de creación por sesión de página. Cancela la solicitud anterior antes de iniciar otra y cancélala cuando el componente se desmonte. El challenge del servidor es de un solo uso, los ID de credencial tienen una restricción única y los envíos duplicados devuelven un resultado idempotente en lugar de crear otra fila.
capability -> policy gate -> one challenge -> user consent
| | |
fallback feature flag server verify -> persist4. Validar el registro por completo
El servidor verifica challenge, origin, RP ID, firma, user handle, política de atestación e ID de credencial. Nunca confíes en un resultado de “creación exitosa” proveniente del cliente. Si no se requiere la atestación del dispositivo, elige una política de atestación más simple y declara el balance entre privacidad y riesgo.
5. Gestionar la sincronización y la recuperación
Una passkey sincronizada puede aparecer después de que el usuario cambie de dispositivo, pero la sincronización no equivale a la recuperación de la cuenta. Proporciona una lista de credenciales, revocación individual de credenciales y una ruta de recuperación para los usuarios que pierdan todos sus dispositivos. No reveles la existencia de passkeys a solicitudes no autenticadas.
6. Despliegue canary con telemetría útil
Habilita por navegador, plataforma, tenant y nivel de riesgo. Registra la detección de capacidades, la visualización del aviso, el consentimiento, los fallos de verificación, las cancelaciones/tiempos de espera, las credenciales duplicadas, el fallback a contraseña y los tickets de soporte. Separa “no admitido” de “rechazado por el usuario”; de lo contrario, no podrás saber si debes mejorar el texto o desactivar la funcionalidad.
7. Rollback sin romper cuentas
Usa un flag remoto para detener nuevos intentos de creación mientras se conserva el inicio de sesión con passkeys existentes. Nunca elimines credenciales como parte del rollback de un despliegue; la revocación es una operación a nivel de cuenta. Mantén una ventana de compatibilidad acotada para versiones anteriores de challenge y vuelve a ejecutar pruebas de navegadores y autenticadores cuando cambie el comportamiento.
Ejemplo de respuesta de alta calidad
Implementaría conditional create como una mejora reversible. El cliente detecta la capacidad y luego verifica el estado de la cuenta, la solidez de la autenticación reciente y un feature flag; se aplica el límite de una solicitud por página y AbortController cancela duplicados. El servidor genera un challenge de un solo uso y verifica challenge, origin, RP ID, firma e ID de credencial antes de la persistencia. Los intentos no admitidos, cancelados o con tiempo de espera agotado regresan al inicio de sesión con contraseña y nunca se convierten en fallos de autenticación. Haría un canary por plataforma y riesgo mientras monitoreo capacidades, consentimiento, errores de verificación, credenciales duplicadas, fallback y tickets de recuperación. Desactivar el flag detiene nuevas creaciones pero mantiene disponibles las passkeys existentes y la revocación.
Errores comunes
- Error → verificar únicamente si existe
PublicKeyCredential→ el objeto no demuestra que conditional create o un autenticador estén disponibles; solución: usa detección de capacidades y mantén un fallback. - Error → llamar silenciosamente a create al cargar la página → el usuario no dio su consentimiento y es probable que aparezcan avisos duplicados; solución: actívalo en un momento explícito de alta confianza y permite que el usuario continúe.
- Error → confiar en un resultado exitoso del lado del cliente → el challenge, origin o la vinculación de la cuenta pueden no estar verificados; solución: completa la verificación del registro en el servidor.
- Error → eliminar credenciales nuevas durante un rollback → el rollback de un release se convierte en la destrucción de cuentas; solución: deshabilita la creación de nuevas credenciales y gestiona la revocación por separado.
Preguntas de seguimiento y respuestas
¿Se debe solicitar confirmación todos los días después de que un usuario la rechace?
No. Registra un período de enfriamiento local y la versión de la política. Vuelve a preguntar solo cuando el riesgo de la cuenta, el dispositivo o las condiciones del producto cambien sustancialmente; rechazar la solicitud no debe afectar el inicio de sesión con contraseña.
¿Qué sucede si la misma cuenta tiene dos filas con el mismo ID de credencial?
Haz que el ID de credencial sea único, haz que el registro sea idempotente y registra la fuente. Si ya existen duplicados, congela nuevas escrituras y fusiona o revisa por usuario e ID de credencial; nunca sobrescribas uno silenciosamente.
La capacidad es compatible pero el éxito cae repentinamente. ¿Qué inspeccionas primero?
Segmenta por versión de navegador, plataforma, autenticador y código de error para separar cancelaciones, tiempos de espera agotados, rechazos de políticas y fallos de verificación en el servidor. Pausa la cohorte del flag afectada, mantén el inicio de sesión con contraseña y passkeys existentes, soluciona la causa y revalida con una cohorte pequeña.