Credential Management API: diseña un inicio de sesión seguro
Cómo la Credential Management API media el inicio de sesión, conserva la elección de la persona y deja la validación en el servidor.
Quieres la documentación estructurada de Identidad?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
La Credential Management API ofrece a un sitio una forma mediada por el navegador de solicitar, guardar y recuperar objetos de credencial. No convierte al navegador en un proveedor de identidad ni crea una sesión por sí sola. Un inicio de sesión fiable une la intención de la persona, la mediación del navegador, la validación del servidor y una alternativa clara cuando algo no está disponible.
El documento W3C Credential Management Level 1 es un Working Draft, no una recomendación final del W3C. Describe el contenedor y la mediación, pero su madurez no garantiza un comportamiento final e idéntico entre navegadores. La referencia de Credential Management API en MDN describe las interfaces y su compatibilidad. Estas fuentes separan una capacidad de API, una operación autorizada por la persona y una sesión autenticada.
Comienza Con El Contrato De Inicio De Sesión
Antes de llamar a navigator.credentials, describe la tarea visible. Puede ser continuar un trabajo guardado, crear una cuenta o confirmar una acción sensible. Esa respuesta decide qué tipo de credencial ofrecer, qué consentimiento mostrar y qué conservar si la operación se cancela.
Trata el contenedor de credenciales como un límite del navegador, no como una base de cuentas. La API puede entregar un objeto cuando el navegador y la persona permiten la solicitud. La aplicación sigue siendo responsable de la política de cuentas, las sesiones, la autorización y la recuperación.
Usa estados separados: inicio inactivo, intención registrada, solicitud mediada, cancelación, credencial recibida, validación pendiente, sesión creada y recuperación disponible. Así la interfaz no anuncia que la sesión empezó mientras el servidor aún procesa la respuesta.
La elección explícita mejora la privacidad y la accesibilidad. Ofrece un control con etiqueta, explica qué relación de cuenta se intentará y avisa que puede aparecer un aviso del navegador. No abras una operación solo al cargar la página.
La vinculación de cuentas necesita un contrato más preciso. Una credencial no debe reemplazar ni combinar sesiones sin confirmación. Pregunta si se quiere entrar, vincular otra credencial o cambiar de cuenta, y conserva el trabajo sin guardar.
Entiende La Mediación Del Navegador
La API separa los tipos de credencial de la mediación. Puede incluir credenciales de contraseña, federadas u otras que implemente el navegador. La disponibilidad depende del navegador, el proveedor, la política y el contexto actual.
La mediación expresa cuánta interacción se necesita. Una ruta silenciosa o condicional puede ayudar a una persona que vuelve; una ruta requerida hace visible la acción. La ausencia de resultado no prueba que no exista una cuenta o una credencial.
Una llamada puede fallar antes de contactar al proveedor. El contexto puede no ser seguro, faltar la interfaz o existir una política que bloquee la operación. Una rama de compatibilidad puede mostrar otro método, pero no fabricar una credencial.
El aviso del navegador forma parte del recorrido. Explica la acción antes de invocarla, conserva el foco y ofrece cancelación. Una negativa es una decisión válida; devuelve a la persona a las opciones sin repetir el aviso automáticamente.
Los objetos de credencial pueden contener material sensible. No los pongas en URL, etiquetas de analítica, capturas, errores ni tickets. Envía solo los campos necesarios por el canal seguro habitual y registra únicamente una fase resumida.
La guía de privacidad de WebAuthn explica que una capacidad del navegador no demuestra que exista una credencial ni identifica a una persona. Aplica la misma cautela a esta API.
Mantén La Validación En El Servidor
El servidor es la autoridad para la cuenta y la sesión. Debe validar el intercambio según el tipo de credencial y el proveedor, vincularlo a la parte confiante y rechazar valores caducados o reutilizados. Una devolución de JavaScript no establece esos hechos.
Vincula cada solicitud a un estado controlado por la aplicación y con caducidad. Al regresar, comprueba el tipo, la audiencia cuando corresponda y la acción pendiente. Comprueba un nonce o una firma solo cuando el protocolo de la integración lo exija. Usa la misma política de sesión para contraseña y credencial del navegador.
Crear una sesión y guardar una credencial son decisiones distintas. El resultado puede iniciar sesión, registrar, vincular o solo devolver un perfil validado. Explica cuál ocurrió y ofrece una salida que termine la sesión de la parte confiante. Esa salida no cierra por sí sola la sesión del proveedor ni elimina una credencial guardada por el navegador.
Los errores deben ayudar sin revelar si una cuenta existe. Usa mensajes coherentes para credenciales inválidas, expiradas o desconocidas cuando la enumeración sea un riesgo. Guarda solo datos resumidos para distinguir navegador, cancelación, proveedor, servidor y tiempo de espera.
La recuperación pertenece a la aplicación. Ofrece restablecimiento, verificación de soporte u otra vía solo si el producto ya la autoriza. No pidas historial de navegación ni un perfil completo. Un enlace de recuperación debe caducar y quedar invalidado tras su uso.
La guía de partición del almacenamiento explica por qué una credencial o sesión puede verse distinta en un contexto incrustado. Trátalo como un resultado de contexto y ofrece una transferencia propia y clara.
Diseña Alternativas Y Mensajes Accesibles
Un flujo resistente tiene una opción mediada y otra comprensible: contraseña, página propia del proveedor, enlace de correo o recuperación autorizada. La alternativa no elude una política del navegador; es la ruta normal cuando falta compatibilidad o la persona rechaza el aviso.
Conserva el trabajo entre ramas. Si se cierra el aviso, vuelve a la pantalla conocida con los campos no sensibles. Si hay tiempo de espera, explica la incertidumbre y crea un estado nuevo para reintentar. Nunca muestres éxito antes de la validación.
El estado accesible es parte de la corrección. Anuncia que se abrirá un aviso, que fue cancelado o que se necesita otra acción. Mueve el foco al mensaje y da un motivo a los controles desactivados. Prueba zoom, alto contraste, lectores de pantalla y nombres largos.
La localización debe conservar el significado de seguridad. Traduce proveedor, cuenta, cancelación, caducidad y recuperación sin cambiar si se creó una sesión. Mantén los nombres oficiales de la API y traduce las instrucciones que los rodean.
Usa una tabla pequeña de aceptación. Con cuentas sintéticas prueba aprobación, rechazo, cancelación, API ausente, proveedor no disponible, estado caducado, respuesta inválida, conflicto, cierre de sesión y recuperación. Registra mensaje, resultado de sesión, trabajo conservado y fase resumida.
No construyas descubrimiento de cuentas con la API. Una credencial ausente, un método bloqueado y un rechazo pueden parecer iguales, pero no significan lo mismo. Conserva el contenido público cuando el acceso no sea obligatorio y explica la recuperación cuando sí lo sea.
Revisa Privacidad Y Límites Del Producto
Minimiza los datos de credencial. Recoge solo lo necesario, limita la retención y restringe el acceso de soporte. Un evento puede guardar fase, revisión, familia del navegador, categoría del proveedor y resultado visible sin conservar el objeto.
No uses la disponibilidad como huella. La política, el perfil, el proveedor y las actualizaciones pueden cambiarla. No demuestra identidad, dispositivo, ubicación ni cuenta. Debe orientar una opción actual, no crear una etiqueta persistente.
Revisa los límites de origen y contexto. Llama a la API desde el origen previsto y usa una referencia autorizada por servidor para cualquier transferencia. No expongas una credencial en una cadena de consulta y explica la relación entre componente, sesión propia y proveedor.
Prueba los cambios como contratos visibles. Repite recorridos sintéticos cuando cambie el navegador, proveedor, código de cuentas, texto de consentimiento o almacenamiento. Compara aviso, elección, validación, duración de sesión, alternativa y eliminación.
Separa estado del navegador y estado de cuenta en los accesorios de prueba. Un perfil limpio representa el primer uso y uno recurrente las elecciones guardadas. Etiqueta cada perfil por propósito y elimina los accesorios al cerrar la ventana de pruebas.
Asigna responsable a cada transición. La interfaz controla foco y texto; el navegador, la mediación; el proveedor, su cuenta; el servidor, validación, sesión y revocación. Ante una duda informa de la fase y responsable en vez de repetir sin límite.
Planifica interrupciones normales. La persona puede cerrar el aviso, perder red, recargar o volver tras caducar el estado. Cada rama termina con un mensaje y una acción acotada. El reintento crea estado nuevo y no repite el objeto.
Explica el contrato al soporte. Distingue credencial del navegador, cuenta del proveedor, sesión de la parte confiante y referencia de recuperación. Solicita el identificador resumido más pequeño y nunca una contraseña, objeto completo o perfil entero.
Las mismas fronteras ayudan a comparar navegadores. Mantén constantes la revisión, el proveedor, la cuenta sintética y la acción, y registra solo la rama visible y el resultado del servidor. Una diferencia es una observación de compatibilidad, no una conclusión sobre la persona.
Mantén precisas las notas de versión. Indica la rama afectada, los navegadores compatibles y la alternativa disponible, y aclara si las sesiones existentes siguen válidas. No prometas que siempre aparecerá un aviso o que siempre se ofrecerá una credencial guardada: dependen del proveedor, la política, el perfil y la decisión de la persona.
La responsabilidad del ciclo debe estar visible. La interfaz registra la intención y conserva la tarea, el navegador media el aviso, el proveedor gestiona su cuenta y el servidor valida y revoca la sesión. El traspaso usa una fase y una caducidad breves, nunca la credencial completa.
La revisión de privacidad incluye los fallos. Un aviso cancelado, una API ausente y una respuesta inválida pueden mostrar la misma pantalla pero requieren acciones distintas. Mantén el mensaje útil y la telemetría mínima, y comprueba la eliminación del estado temporal después de cada caso negativo.
BotBrowser permite transportar un perfil de navegador repetible entre sistemas operativos compatibles para revisar el propio flujo de inicio de sesión. No puede controlar la mediación de Credential Management API, no aprueba credenciales del proveedor y no sustituye la validación del servidor ni la política de sesión de la parte confiante.
Fuentes Públicas
El documento W3C Credential Management Level 1 es un Working Draft, no una recomendación final del W3C. Describe el contenedor y la mediación, pero no debe leerse como garantía final de compatibilidad entre navegadores. La referencia de MDN resume la API y su compatibilidad. La documentación de perfiles multiplataforma de BotBrowser respalda únicamente la revisión repetible. La disponibilidad real requiere probar el contrato del navegador, proveedor y servidor.
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.