Consigna y alcance
El producto desea vincular una pequeña configuración cifrada a la credencial WebAuthn de un usuario para reducir el estado del lado del servidor. Explique cuándo encaja largeBlob, en qué se diferencian el registro y la autenticación, cómo comprueba los resultados el cliente y cómo el inicio de sesión y la exactitud de los datos sobreviven a dispositivos no compatibles.
Qué evalúa el entrevistador
- Si sabe que largeBlob es información opaca asociada a una sola credencial, no un almacenamiento general del cliente.
- Si distingue las entradas y salidas del registro
supportde las de autenticaciónreadywrite. - Si toma en cuenta la capacidad del autenticador, las credenciales detectables (discoverable credentials) y la restricción de escritura en una sola credencial.
- Si diseña la detección de capacidades, el respaldo en servidor, la privacidad y la degradación ante fallos.
Preguntas para clarificar
- ¿Los datos deben viajar con esta credencial, o bastan una base de datos en el servidor e IndexedDB?
- ¿Cuáles son los requisitos de tamaño, confidencialidad, recuperabilidad y entre dispositivos?
- ¿El autenticador de destino admite largeBlob y la credencial es detectable?
- ¿Cómo se recupera el sistema tras una escritura fallida, la pérdida de una credencial o un cambio de dispositivo?
Una respuesta de 30 segundos
Trataría a largeBlob como una capacidad opcional del autenticador, no como almacenamiento principal. Durante el registro solicitaría support: preferred e inspeccionaría supported; durante la autenticación utilizaría read o bien write, apuntaría exactamente a una credencial para una escritura y comprobaría blob o written. Cifraría y limitaría el tamaño de los datos y mantendría una copia recuperable en el servidor. La falta de capacidad, la insuficiencia de espacio o el fallo de escritura deben degradar al estado del servidor sin bloquear el inicio de sesión ni tratar una escritura no confirmada como exitosa.
Diseño paso a paso
1. Elegir el límite de datos adecuado
La especificación define largeBlob como datos opacos asociados a una credencial. Es adecuado para configuraciones pequeñas o material de claves vinculados a la credencial, no para perfiles de usuario, sincronización entre credenciales o una base de datos de objetos. Los autenticadores tienen una capacidad limitada, por lo que el servidor debe conservar información de recuperación.
2. Usar el registro solo para la detección de capacidades
La extensión de registro acepta largeBlob: { support: "preferred" } o required. supported indica si la credencial creada puede almacenar un blob; el registro no escribe uno. Con required, los autenticadores no compatibles quedan excluidos, por lo que debe medirse el costo de compatibilidad antes de hacerlo obligatorio.
3. Separar lecturas y escrituras durante la autenticación
La autenticación puede solicitar read: true o proporcionar write; suministrar ambos falla. Una escritura requiere que allowCredentials contenga exactamente una credencial, y el éxito se reporta mediante written. Un miembro blob está presente únicamente tras una lectura exitosa, no simplemente porque exista el objeto de la extensión.
4. Diseñar privacidad, recuperación y alternativas (fallback)
Los datos del autenticador son opacos, no están automáticamente cifrados por la aplicación. El cliente y el servidor deben proporcionar cifrado, control de versiones y comprobaciones de integridad. Si la credencial no está disponible, el dispositivo carece de soporte, la capacidad es insuficiente o el usuario lo rechaza, utilice la copia del servidor. Registre la capacidad y el resultado, nunca el contenido del blob.
Respuesta modelo de alta calidad
No utilizaría largeBlob como reemplazo del estado del lado del servidor. Es útil para vincular un valor opaco pequeño a una sola credencial WebAuthn. Durante el registro solicitaría support: preferred e inspeccionaría supported; durante la autenticación elegiría read o bien write, apuntaría a una credencial para la escritura y comprobaría blob o written. La aplicación se encarga del cifrado, el versionado y la integridad, mientras que el servidor mantiene una copia recuperable. Los autenticadores no compatibles, las restricciones de credenciales detectables, los errores de capacidad, los fallos de escritura y los cambios de dispositivo se degradan al estado del servidor sin bloquear la autenticación. Solo exigiría la característica cuando el producto acepte una menor compatibilidad y cuente con un plan de migración. Esto aprovecha el almacenamiento del autenticador sin hacer que el inicio de sesión o la recuperación dependan de él.
Errores comunes
- Tratar largeBlob como IndexedDB, una cookie o almacenamiento ilimitado sincronizado en la nube.
- Asumir que se puede escribir un blob durante el registro.
- Suministrar
readywritejuntos o nombrar múltiples credenciales para una escritura. - Comprobar únicamente que el objeto de la extensión existe en lugar de
supported,blobowritten. - Escribir datos sensibles en un blob opaco sin cifrado por parte de la aplicación.
- Bloquear el inicio de sesión cuando un autenticador carece de soporte en lugar de recurrir al servidor.
Preguntas de seguimiento y respuestas
¿Cómo se elige entre preferred y required?
preferred permite un autenticador no compatible y una alternativa de respaldo; required lo excluye. Es preferible preferred a menos que el producto acepte una menor cobertura y realmente dependa de dicha capacidad.
¿Por qué una escritura debe apuntar exactamente a una credencial?
La especificación utiliza un único destino allowCredentials para identificar la credencial que se está actualizando. Múltiples candidatos generan un fallo de operación no compatible, por lo que la aplicación debe resolver primero la credencial del usuario.
¿Cuál es el plan de migración de dispositivos?
Trate el blob como una caché o copia de claves opcional y mantenga el material de recuperación en el servidor. Un nuevo dispositivo obtiene el estado del servidor a través de un nuevo registro o autenticación; no asuma que el blob del autenticador se sincroniza entre dispositivos.