Planteamiento y contexto
Eres el responsable del punto de entrada de inicio de sesión empresarial para un sitio multilingüe. El equipo de producto quiere que el navegador ofrezca una cuenta del proveedor de identidad solo después de que el usuario tome una decisión explícita, mientras que los requisitos de privacidad prohíben depender de cookies de terceros para el rastreo. Diseña la colaboración entre la parte que confía (RP, relying party), el proveedor de identidad (IdP) y el servidor, considerando navegadores no compatibles, denegación del usuario, múltiples IdPs, creación de sesiones y cierre de sesión.
Qué está evaluando el entrevistador
Una respuesta sólida trata a FedCM como una interfaz de federación de identidades mediada por el navegador, no como un reemplazo de la validación de tokens. La RP solicita la identidad con navigator.credentials.get(), el navegador presenta las opciones de cuenta y el IdP devuelve una aserción o resultado de autorización de corta duración. El servidor sigue validando la firma, el emisor (issuer), la audiencia (audience), el nonce y el estado antes de crear una sesión local. La respuesta también debe diferenciar los límites de cookies de terceros, la política de permisos (permission policy), la elección del usuario y un flujo de contingencia tradicional de redirección OAuth/OIDC.
Preguntas de clarificación para hacer primero
Protocolo y modelo de confianza
Confirma si el IdP utiliza OAuth, OIDC o una aserción personalizada, si se permiten múltiples IdPs y cómo administra el servidor la configuración de JWKS, emisor y audiencia. FedCM no reemplaza la rotación de claves ni la validación de tokens en el límite del IdP.
Requisitos del navegador y de privacidad
Confirma los navegadores objetivo, iframes embebidos, directivas empresariales y la postura actual sobre cookies de terceros. La compatibilidad y el comportamiento de la interfaz de usuario de FedCM dependen del navegador; no se puede asumir el comportamiento de Chrome en todas partes.
Vinculación de cuentas y política de cierre de sesión
Confirma si un sujeto externo puede mapearse a una sola cuenta local, cómo se manejan las direcciones de correo electrónico duplicadas, si el cierre de sesión global debe notificar al IdP y si una solicitud denegada puede recurrir al inicio de sesión mediante contraseña o correo electrónico.
Estructura de respuesta en 30 segundos
“Trato a FedCM como una capa de selección de identidad controlada por el navegador. La RP obtiene un estado de un solo uso desde su servidor y luego llama a navigator.credentials.get(). El navegador presenta un selector de cuentas del IdP y el IdP devuelve un resultado de identidad vinculado al protocolo. El servidor valida el emisor, la firma, la audiencia, el nonce, el estado y el mapeo de cuentas antes de crear la sesión del sitio. Los navegadores no compatibles, los bloqueos de permisos, las cancelaciones y los rechazos del servidor son estados distintos. El flujo de contingencia es OAuth/OIDC con protección CSRF y PKCE. El cierre de sesión debe distinguir la sesión del sitio de la sesión del IdP; borrar una cookie no equivale a un cierre de sesión global.”
Respuesta detallada paso a paso
Paso 1: Configurar la RP y los IdPs
El servidor almacena el emisor, client ID, endpoint de JWKS, protocolo permitido y política de callback para cada IdP de confianza. El frontend recibe únicamente un identificador de configuración aprobado por el servidor y nunca acepta una URL de IdP arbitraria proveniente del usuario. Para despliegues multi-tenant, vincula una lista de permitidos a cada tenant para evitar redirecciones abiertas o la entrega de tokens entre tenants.
Paso 2: Crear el estado de inicio de sesión de un solo uso
Una vez que el usuario inicia el proceso de acceso, el servidor de la RP crea un estado impredecible, un nonce y un registro de flujo de corta duración vinculado a la sesión del navegador, al tenant y a la ruta de retorno. El frontend envía a FedCM los parámetros provistos por el servidor. El estado y el nonce siguen siendo valores de un solo uso controlados por el servidor; el frontend no debe generarlos ni reutilizarlos.
Paso 3: Realizar la solicitud mediada por el navegador
El frontend invoca navigator.credentials.get() en un contexto seguro y bajo la política de permisos requerida. El navegador presenta un selector de cuentas y continúa únicamente tras la selección explícita del usuario. Las solicitudes de FedCM llevan un destino de búsqueda (fetch destination) dedicado para que el servidor pueda identificar el flujo de identidad; el frontend no debe interpretar la aparición de la UI como un éxito de autenticación.
Paso 4: Validar el resultado de identidad en el servidor
El servidor comprueba emisor, firma, expiración, audiencia, nonce, estado y sujeto, y luego mapea la identidad externa mediante una política explícita. El correo electrónico es un atributo auxiliar, no una clave de fusión automática de cuentas. Solo tras la validación el servidor emite la sesión del sitio y registra el IdP, el sujeto, la hora de autenticación y las señales de riesgo pertinentes.
Paso 5: Diseñar estados de fallo y de contingencia (fallback)
Los navegadores no compatibles, los bloqueos de permisos, la cancelación del usuario y los fallos de red requieren un manejo independiente. Un fallback de redirección OAuth/OIDC utiliza PKCE, un URI de redirección exacto, estado y nonce; y retorna a través de la misma capa de mapeo de cuentas del servidor. La interfaz de usuario explica la siguiente acción sin exponer emisores, tokens ni errores de validación internos.
Paso 6: Manejar múltiples IdPs y vinculación de cuentas
Cuando se permiten varios IdPs, la página presenta una lista aprobada por el negocio y el navegador junto con el IdP completan la selección de la cuenta. El servidor utiliza (issuer, subject) como la clave externa estable y nunca fusiona silenciosamente solo por correo electrónico. Agregar un IdP requiere una sesión autenticada o verificación reforzada (step-up) y genera un evento auditable de vinculación o desvinculación.
Paso 7: Cierre de sesión, revocación y despliegue gradual
El cierre de sesión del sitio revoca la sesión local, limpia las cookies seguras e invalida los refresh tokens; si el protocolo y el IdP lo admiten, el cliente también puede invocar el cierre de sesión del IdP. Es posible que FedCM no cubra todas las capacidades de cierre de sesión dependientes de cookies, por lo que se debe explicar la diferencia entre cerrar sesión en el sitio y cerrar sesión en el proveedor. Realiza el despliegue según la capacidad del navegador y la tasa de errores con un interruptor de fallback observable.
Ejemplo de respuesta de alta calidad
Separaría la elección de identidad en el navegador, la prueba del IdP y la creación de la sesión de la RP. El servidor de la RP genera estado de corta duración, nonce y datos de flujo vinculados al tenant. El frontend inicia FedCM en un contexto seguro; el navegador muestra el selector de cuentas y el IdP devuelve un resultado tras la confirmación del usuario. El servidor valida la firma JWKS del emisor, audiencia, nonce, estado, expiración y sujeto, y luego mapea (issuer, subject) a una cuenta local antes de crear la sesión del sitio.
Los navegadores no compatibles, los bloqueos de políticas, las cancelaciones y los fallos de red permanecen como estados independientes y recurren a OAuth/OIDC con PKCE. El fallback mantiene la misma política de validación y vinculación en el servidor. Múltiples IdPs provienen únicamente de una lista de permitidos del servidor, y el correo electrónico no es una clave de fusión automática. El cierre de sesión revoca la sesión del sitio; el cierre de sesión en el proveedor es una capacidad independiente que se le explica al usuario. Durante el despliegue monitorearía el éxito, las cancelaciones, el fallback y los conflictos de vinculación de cuentas por navegador e IdP, con un interruptor que deshabilite únicamente el punto de entrada de FedCM si los errores aumentan.
Errores comunes
- Error: Tratar el resultado de FedCM como una sesión autenticada. → Por qué falla: La elección mediada por el navegador no valida emisor, firma ni nonce. → Solución: Envía cada resultado a través de una única ruta de validación y creación de sesiones en el servidor.
- Error: Emparejar una cuenta existente únicamente por correo electrónico. → Por qué falla: El correo electrónico puede no estar verificado, haber sido reciclado o estar duplicado entre IdPs. → Solución: Usa
(issuer, subject)como clave externa y exige confirmación explícita para la vinculación basada en correo electrónico. - Error: Guardar un token en el almacenamiento del frontend tras un fallo de FedCM. → Por qué falla: Amplía la exposición a XSS y elude la política de sesiones existente. → Solución: Permite que el servidor intercambie el resultado y configure una cookie de sesión protegida; el frontend solo maneja el estado.
- Error: Asumir que el cierre de sesión del sitio cierra la sesión del usuario en el IdP. → Por qué falla: Las sesiones tienen ciclos de vida y capacidades de protocolo diferentes. → Solución: Revoca cada sesión por separado y comunica el alcance del cierre de sesión.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cómo se relaciona FedCM con una redirección OAuth ordinaria?
FedCM cambia la forma en que el navegador media la selección de cuentas y la interacción entre sitios; OAuth/OIDC siguen proporcionando autorización y prueba de identidad. Ambos pueden compartir emisor, nonce, estado, PKCE y mapeo de cuentas en el servidor. Un fallback no debe eliminar esas comprobaciones.
Pregunta de seguimiento 2: ¿Por qué las restricciones a cookies de terceros afectan a la federación?
Un IdP embebido anteriormente podía usar una cookie de terceros para reconocer a un usuario conectado. Las cookies particionadas o bloqueadas requieren, en su lugar, una elección explícita y visible para el usuario. FedCM reduce el reconocimiento implícito entre sitios, pero no decide los permisos de la aplicación.
Pregunta de seguimiento 3: ¿Se puede reemplazar silenciosamente un IdP denegado por otro?
No trates la denegación como un consentimiento implícito. Ofrece otro IdP aprobado o la entrada de contraseña como una acción explícita del usuario, y crea un estado nuevo, nonce y datos de flujo para el proveedor seleccionado en lugar de reutilizar una solicitud ya finalizada.
Pregunta de seguimiento 4: ¿Cómo demuestras que un despliegue gradual no perjudicó el inicio de sesión?
Segmenta las métricas de éxito, cancelación, bloqueo de políticas, fallback, conflictos de cuentas y tiempo de finalización por navegador, IdP, región y contexto embebido. Genera alertas ante anomalías de emisor, fallos de firma y reutilización de nonces. Mantén un interruptor en el servidor que deshabilite únicamente FedCM dejando intacta la ruta establecida de validación de OAuth.