FedCM y privacidad del navegador: diseñar flujos de cuenta
Cómo funciona el límite visible de FedCM y cómo diseñar, probar y recuperar el acceso sin depender del seguimiento entre sitios.
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.
Federated Credential Management, o FedCM, ofrece una ruta mediada por el navegador para que un proveedor de identidad ayude a una parte dependiente a iniciar sesión. Según la cuenta y el permiso previo, el navegador puede pedir al usuario que elija o apruebe una cuenta; un usuario recurrente que cumpla los requisitos puede volver a autenticarse automáticamente sin el mismo selector. La aplicación debe separar la primera aprobación del regreso y no suponer que todos los flujos muestran un selector de cuentas. La aplicación deja de tratar al proveedor embebido como un almacén de cookies de terceros sin límites.
FedCM es una API de identidad, no un botón universal ni una forma de reconocer un navegador desconocido. El resultado depende de disponibilidad, cuenta, elección del usuario, configuración y política del proveedor. El producto debe definir primero el recorrido y su alternativa, y usarlo solo para una relación autorizada.
Vincule cada flujo público con el algoritmo actual de inicio de sesión RP de la especificación W3C de FedCM: allí se describen la solicitud signin y la credencial devuelta; la creación de una cuenta nueva está en solicitar permiso para registrarse; y la reautenticación automática de una cuenta recurrente es la rama de cuenta elegible del mismo algoritmo. El lector puede comprobar el límite registrando si la prueba usó signin, si apareció una superficie de permiso, si IdentityCredential.isAutoSelected fue true y si el servidor aceptó audience y la vigencia. Ninguna observación autoriza una cuenta por sí sola, y que no aparezca un aviso no demuestra que la persona o el dispositivo sean desconocidos.
Qué cambia con la mediación del navegador
Un flujo federado tradicional puede redirigir al proveedor o integrar su contenido. Antes, el proveedor embebido podía depender de cookies de terceros para recordar una sesión. FedCM traslada la selección de cuenta y parte del intercambio a una superficie del navegador aprobada por el usuario.
El navegador no decide si la cuenta está autorizada. El servidor de la parte dependiente valida issuer, audience, vigencia, enlace de solicitud y firma, aplica sus reglas de vinculación y crea la sesión. Un aviso aceptado no demuestra autorización y su ausencia no identifica a una persona.
El selector de cuenta es un límite visible. Explique qué proveedor participa, qué relación se crea y qué ocurre si se rechaza. No oculte el rechazo mediante redirecciones repetidas ni exija una credencial para leer contenido público no relacionado.
FedCM no vuelve privadas todas las solicitudes. La parte dependiente procesa el resultado y su sesión; el proveedor opera su servicio de cuenta. Revise URL, cuerpos, registros, analítica, soporte, redirecciones y borrado. El selector no sustituye la minimización de datos.
La API, los requisitos y la presentación cambian entre versiones. Registre el rango probado y el contrato del proveedor. No afirme que todos los navegadores muestran los mismos campos; documente el flujo concreto y su alternativa.
Definir el contrato de la parte dependiente
Empiece por el recorrido: dónde se solicita acceso, qué cuentas se ofrecen, qué disclosure se muestra y qué estado debe sobrevivir a cancelación o reintento. La aserción completa una tarea limitada y visible, como crear sesión o vincular cuenta.
La vinculación debe ser explícita. Si ya existe una sesión local, indique si la cuenta nueva inicia, vincula o reemplaza. Exija una acción antes de combinar registros y preserve el trabajo cuando haya conflicto.
El servidor valida cada respuesta: issuer, audience, nonce o enlace, expiración y firma. Limite intercambios fallidos y trate replay de forma determinista. Registre la etapa de fallo sin conservar el token completo.
La sesión de aplicación necesita una vida definida. Rote o revoque estado cuando cambie la cuenta y ofrezca un cierre que termine la sesión dependiente. El selector del navegador no reemplaza logout, recuperación ni permisos del servidor.
Si hay varios proveedores, presente opciones comprensibles y aclare si crean cuentas separadas o vinculables. Un proveedor no disponible no debe bloquear una alternativa local ya autorizada. No reabra sin límite un selector rechazado.
Consentimiento, divulgación y control
El primer aviso debe decir quién solicita, qué cuenta se usa y qué hará la aplicación. Coloque la explicación cerca del inicio. Nombre y avatar solo sirven al propósito declarado y el usuario debe poder corregir una cuenta inesperada.
El consentimiento no autoriza toda operación futura. Vuelva a pedirlo cuando cambien finalidad, vínculo o datos. Conserve el registro mínimo y permita revocar sesión o desvincular. La elección recordada por el navegador no sustituye el registro contractual del producto.
Rechazar es un resultado normal. Mantenga funciones públicas, muestre acceso local o recuperación cuando exista y explique que se puede intentar después. No culpe al navegador ni obligue a revelar identidad para contenido público.
La selección de cuenta puede ser sensible. No ponga identificadores, tokens o perfil detallado en URL, capturas, etiquetas analíticas o excepciones. Use cuentas sintéticas y elimine fixtures temporales al cerrar el caso.
Explique también el cierre. Salir de la aplicación puede dejar abierta la cuenta del proveedor, y revocar al proveedor es otra acción. Distinga ambas y enlace los controles del proveedor cuando corresponda.
Cookies de terceros y límites de almacenamiento
FedCM reduce dependencia de cookies de terceros, pero no concede una excepción general de almacenamiento. El proveedor no debe asumir lectura en iframe tras la aprobación. La parte dependiente guarda su propia sesión y el proveedor documenta la ruta propia de gestión.
El particionado puede hacer que el proveedor parezca nuevo bajo otro sitio superior. Es contexto, no identidad. La guía de particionado describe el estado vacío y un handoff de primera parte controlado por el usuario.
No use el resultado como fingerprint. El prompt puede faltar por navegador, cuenta, configuración, permiso, política o versión. Elija la rama por la función visible, no por propiedades o tiempos.
Las señales de red requieren revisión separada. Proveedor y parte dependiente ven el contexto necesario de sus solicitudes. La guía de identidad de red explica por qué un acceso no es una identidad de red estable.
El borrado cubre ambos lados. La parte dependiente elimina sesión y vínculo según su política; el proveedor ofrece su propio control. Separe registros obligatorios de los datos eliminables y no conserve toda la aserción por haber usado FedCM.
Construir una alternativa resistente
Un flujo robusto combina ruta mediada, ruta propia del proveedor y recuperación aprobada. La alternativa no evita una política del navegador: permite continuar cuando la API no existe, el usuario rechaza o la cuenta necesita ayuda.
La ruta propia usa un handoff breve y autorizado por servidor. No incluya credenciales en la URL; vincule la referencia a parte, acción y expiración, e invalídela tras usarla. Al cancelar, conserve formulario o borrador y vuelva a una pantalla conocida.
La recuperación tiene propietario y límites de frecuencia. Ofrezca búsqueda, credencial local o verificación solo si el producto ya lo autoriza. No pida historial ni desactivar privacidad. Indique si se creó sesión, si se conservó el trabajo y el siguiente paso.
Clasifique antes de repetir: API ausente, cuenta no disponible, rechazo, aserción inválida, handoff expirado y timeout tienen responsables diferentes. Registre etapa, revisión, familia y versión, categoría del proveedor y resultado visible.
Cada rama necesita estado accesible. Un lector de pantalla debe conocer selección disponible, cancelación o recuperación pendiente. Mueva foco al título o error útil y explique un control deshabilitado junto con su alternativa.
Matriz de aceptación para el flujo de cuenta y la alternativa
Use como fuentes del protocolo el algoritmo de inicio de sesión de la parte dependiente en W3C y la referencia de la API FedCM en MDN. Ejecute cada fila con cuentas sintéticas y acéptela solo cuando el resultado observable coincida con el contrato de la aplicación.
| Condición observable inicial | Acción principal | Alternativa visible para el usuario | Evidencia de aceptación |
|---|---|---|---|
| FedCM no está disponible o el proveedor no puede ofrecer una cuenta | No abra un selector | Ofrezca la ruta propia del proveedor o la recuperación aprobada | No se envía ninguna credencial; se anuncia la página alternativa; no existe sesión de la parte dependiente hasta validar en el servidor |
| El usuario rechaza el selector | Termine el intento de FedCM | Mantenga el contenido público y muestre el inicio local o la recuperación | El evento registra declined; se conserva el trabajo actual; no se crea sesión |
| El usuario cancela, expira el handoff o vence el tiempo del servidor | Detenga el intercambio e invalide la referencia | Vuelva a la pantalla conocida con un reintento limitado | La página indica que no se completó el inicio, conserva el borrador y el reintento no reutiliza la referencia expirada |
| La aserción falla la comprobación de issuer, audience, nonce, firma o expiración | Rechace la respuesta en el servidor | Muestre la recuperación aprobada | El servidor devuelve un resultado no exitoso, guarda solo la etapa desidentificada y la interfaz nunca afirma que hubo inicio |
| La cuenta devuelta entra en conflicto con la cuenta local activa | No conecte ni sustituya registros automáticamente | Pida una elección explícita de conectar, cambiar o recuperar | El trabajo y la sesión existentes no cambian hasta confirmar; la sesión final corresponde a una sola cuenta |
Recorrido de aceptación de extremo a extremo
Use el algoritmo de W3C y la referencia de API de MDN anteriores como fuente para los pasos del navegador, y la configuración documentada del proveedor como fuente para la elegibilidad. En un flujo normal, el usuario pulsa Iniciar sesión, la parte dependiente llama a FedCM desde un perfil de prueba limpio y el proveedor configurado ofrece una cuenta sintética. El navegador muestra el selector; tras la aprobación, la parte dependiente envía la aserción al servidor. El servidor valida issuer, audience, nonce, firma y expiración, crea exactamente una sesión de la parte dependiente y devuelve al usuario a la tarea guardada con un mensaje accesible. El paquete de evidencia contiene etapa, categoría del proveedor, resultado de validación, resultado de sesión y mensaje visible, nunca la aserción.
Use ejecuciones negativas controladas para identificar al responsable:
| Resultado observable | Cómo distinguirlo | Resultado de aceptación requerido |
|---|---|---|
| API no disponible | navigator.credentials o el método FedCM falta o está bloqueado antes de pedir al proveedor | No hay selector ni intercambio de credenciales; muestre la ruta propia aprobada y registre api_unavailable |
| Rechazo del usuario | El selector apareció y el usuario sintético canceló o rechazó | Registre declined; conserve la tarea; no cree sesión; ofrezca inicio local o recuperación |
| Configuración del proveedor | La API se puede llamar, pero el proveedor no es elegible o no puede ofrecer la cuenta de prueba configurada | Registre provider_not_configured o provider_account_unavailable; no envíe aserción para crear sesión; muestre la ruta del proveedor o recuperación |
| Validación de aserción en servidor | El resultado del selector llega al servidor, pero falla issuer, audience, nonce, firma o expiración | Devuelva resultado no exitoso, registre solo la etapa desidentificada, no cree sesión y muestre recuperación |
La prueba solo pasa cuando la etiqueta de rama, el comportamiento de red, el estado de sesión del servidor, el trabajo conservado y el mensaje visible coinciden. Así se separan capacidad del navegador, decisión del usuario, configuración del proveedor y confianza del servidor sin convertir ningún resultado en señal de identidad.
Probar con cuentas sintéticas
Use cuentas de proveedor y parte dependiente creadas para pruebas. Verifique por separado perfil limpio y recurrente. No guarde direcciones personales, aserciones de producción ni códigos reales; asigne responsables de borrado en ambos sistemas.
Cubra apertura, selector, aprobación, rechazo, cancelación, regreso, reautenticación automática permitida, cierre y recuperación. Compruebe el resultado visible, no solo un callback. La prueba de regreso verifica por separado la concesión previa, la presencia o ausencia del selector y la sesión creada por el servidor. La prueba pasa cuando el servidor crea la sesión prevista y la página comunica el resultado de forma accesible.
Incluya dos cuentas, una ya vinculada a otro usuario local, una sesión de proveedor expirada y una cuenta no ofrecible. La aplicación no debe reemplazar trabajo ni unir registros de forma silenciosa.
Compare navegadores con la misma revisión, configuración y datos. Registre disponibilidad, prompt, acción, resultado de servidor y alternativa. Si cambia una versión, actualice la matriz, no una conclusión universal.
Pruebe cerrar selector, recargar durante callback, perder red, expirar handoff y reiniciar. Evite sesiones duplicadas, preserve los datos de entrada permitidos y ofrezca reintento limitado. Un intercambio fallido no puede mostrarse como acceso completo.
En automatización, cada sesión tiene un solo propietario de perfil. La guía de Selenium cubre aislamiento, versiones y cierre limpio. Las aserciones FedCM pertenecen al límite de la aplicación, no a una lista de fingerprint.
Revisión de versión y operación
Repita el recorrido sintético cuando cambien navegador, proveedor, código, vinculación, texto de consentimiento o storage. Mantenga fixtures pequeños para primera aprobación, rechazo y alternativa, cuenta recurrente, conflicto y recuperación.
Las notas de versión nombran el flujo afectado y la acción del usuario. No presente un cambio de prompt como regla para todas las plataformas. Si hay una alternativa temporal, indique rango afectado y forma de continuar.
Los paneles registran eventos funcionales: aprobación o rechazo, intercambio, motivo de la alternativa, recuperación y revisión. Limite retención y acceso; los agregados no deben reconstruir una identidad entre sitios.
La respuesta a incidentes protege el trabajo. Si falla validación, conserve el formulario permitido, explique y ofrezca recuperación. No empiece limpiando perfiles o copiando cookies; capture evidencia mínima y retire el fixture al terminar.
Verifique periódicamente cierre, desvinculación y borrado. Salir termina la sesión dependiente, desvincular actualiza la relación y un handoff expirado deja de funcionar. Pruebe perfil limpio y recurrente.
El soporte usa el vocabulario de la interfaz para distinguir cuenta de proveedor, sesión dependiente, cuenta local vinculada y referencia de recuperación. Solicite solo el identificador sintético o redactado necesario para localizar la etapa.
Accesibilidad y localización forman parte del contrato. Traduzca propósito, rechazo y recuperación sin cambiar su sentido. Pruebe nombres largos, RTL si se admite, zoom, movimiento reducido y teclado.
La integración debe ser reversible. Si una versión cambia disponibilidad, permita desactivar la ruta principal para un público limitado y conservar la alternativa aprobada. Registre cambio, flujo y acción del usuario.
Fuentes públicas
El documento FedCM de W3C enlazado aquí es un primer borrador público de trabajo, y la página de la API en MDN califica su compatibilidad como limitada y experimental. Use esas páginas como referencias del protocolo y la compatibilidad, y verifique después el proveedor, la versión del navegador y el contrato del servidor que la aplicación admite realmente.
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.