Entrevista general: ¿Cómo elegir FAL1, FAL2 o FAL3 para la identidad federada?

Planteamiento y contexto

Una parte usuaria (RP) integra varios proveedores de identidad (IdPs) para contenido público, administración de empleados y transacciones de alto valor. El equipo trata FAL como "robustez de inicio de sesión" sin definir la inyección de aserciones, la vinculación del titular, la privacidad ni la recuperación. Utilice NIST SP 800-63C para elegir un Nivel de Garantía de Federación y explicar la validación de OIDC y las operaciones.

FAL describe cómo una transacción de federación protege y vincula una aserción. No reemplaza a IAL (verificación de identidad) ni a AAL (robustez del autenticador). El NIST establece que los niveles superiores subsumen los requisitos de los inferiores; FAL3 exige adicionalmente que el suscriptor presente una prueba de un autenticador vinculado directamente a la RP.

Qué está evaluando el entrevistador

• Separación entre verificación de identidad, autenticación de usuario y entrega de aserciones.
• Propiedades de seguridad correctas y límites de FAL1, FAL2 y FAL3.
• Validación de emisor, audiencia, firma, nonce, tiempo de vida y origen de la aserción.
• Manejo de múltiples IdPs, inyección, vinculación del titular, privacidad y recuperación.
• Transformación de la decisión de un nivel en políticas, monitoreo, migración y excepciones.

Preguntas de aclaración

1. ¿El recurso es contenido público, una consola de empleados o una transacción de alto valor?
2. ¿La federación es OIDC, SAML u otro protocolo, y quién emite y valida las aserciones?
3. ¿El diseño debe resistir la inyección de aserciones, la transferencia de tokens o la reproducción tras un robo? ¿Pueden los usuarios presentar un autenticador vinculado?
4. ¿Cómo funcionan los cambios de dispositivo, la recuperación, el uso sin conexión y los dispositivos compartidos?
5. ¿Cómo se mantienen los mapeos de emisor, audiencia, JWKS e inquilinos entre distintos IdPs?

Respuesta en 30 segundos

Elija el FAL a partir del riesgo del recurso, no de la pantalla de inicio de sesión. FAL1 cubre la entrega básica de aserciones; FAL2 añade protección contra ataques de federación como la inyección de aserciones; FAL3 exige adicionalmente una prueba de autenticador vinculado al suscriptor presentada directamente a la RP. Rastree IAL, AAL y FAL por separado. Valide el emisor, la audiencia, la firma, el nonce y el tiempo en OIDC. Reserve FAL3 para operaciones de alto valor y planifique los costos de recuperación, privacidad, rotación de claves y despliegue.

Respuesta a fondo

1. Separar IAL, AAL y FAL

IAL describe la verificación de identidad, AAL describe cómo un usuario demuestra el control de un autenticador y FAL describe la protección de una aserción de IdP entregada a una RP. Un usuario puede tener un AAL fuerte mientras que la transacción de federación tiene un FAL insuficiente; FAL2 no demuestra un nivel de verificación de identidad.

Para cada recurso, registre los tres niveles, los IdPs permitidos, el tipo de aserción, la ruta de recuperación y la retención de auditoría. No asocie "usa OIDC" directamente a un FAL.

2. Comprender los tres niveles de FAL

FAL1 proporciona entrega básica de aserciones de federación para servicios de menor riesgo, pero aún requiere validación de firma, emisor, audiencia, tiempo de vida y sesión.

FAL2 añade una protección más sólida en la entrega de aserciones contra un atacante que inyecta una aserción válida en otra transacción de federación. La RP necesita contexto de transacción explícito, IdPs de confianza y comprobaciones de inyección.

FAL3 se basa en FAL2 y requiere una prueba de autenticador vinculado presentada directamente por el suscriptor, lo que dificulta la transferencia de aserciones. Añade costos de vinculación de dispositivos, recuperación, disponibilidad y privacidad, por lo que no debe ser el valor predeterminado para cada inicio de sesión.

3. Validar una aserción OIDC

Valide la firma del ID Token, iss, aud, exp, iat y el nonce. OpenID Connect requiere comparar el nonce con el valor enviado en la solicitud de autenticación; el componente de ruta de la URL de un emisor forma parte de su identidad.

Obtenga JWKS únicamente de un emisor aprobado y actualícelo de manera controlada cuando falte un kid. No construya URLs de descubrimiento a partir de entradas de usuario ni trate un reclamo de correo electrónico como una clave de identidad entre inquilinos.

4. Resistir la inyección y transferencia de aserciones

Persista en el servidor la solicitud de autorización, el emisor, el client ID, la URI de redireccionamiento, el state y el nonce. El callback debe coincidir con la transacción original; un emisor desconocido, una audiencia incorrecta, un state repetido o un nonce incorrecto detienen el flujo.

Los recursos de alto riesgo también vinculan la transacción, el recurso y la sesión. FAL2 aborda el problema central de inyección de aserciones en federación, pero no reemplaza a PKCE, la identificación del emisor, la audiencia del token ni la autorización del recurso.

5. Diseñar un autenticador vinculado para FAL3

FAL3 requiere que el suscriptor presente la prueba de un autenticador vinculado directamente a la RP. La RP registra la vinculación, verifica la frescura de la prueba y el estado del dispositivo, y gestiona la pérdida, el reemplazo, la revocación y la recuperación.

La recuperación no puede depender únicamente de un inicio de sesión ordinario en el IdP, o podría eludir la vinculación. La recuperación de alto riesgo puede requerir factores independientes, revisión manual o activación diferida; los equipos de producto y soporte deben aceptar costos y tasas de error más altos.

6. Operar con privacidad y múltiples IdPs

Solicite únicamente los reclamos necesarios para el negocio y limite la retención de aserciones y los campos de registro. Los sujetos de diferentes IdPs no deben fusionarse en una sola identidad entre dominios sin un mapeo delimitado por emisor e inquilino.

Monitoree fallas de firma, conflictos de emisor, reproducción de nonce, actualización de JWKS, tamaño de aserción, eventos de recuperación y éxito por FAL. Use solapamiento durante la rotación de claves y mantenga verificable la configuración antigua del emisor durante el TTL de las sesiones en tránsito.

7. Elegir, desplegar y gestionar excepciones

El contenido público generalmente no necesita un FAL alto; una consola de empleados puede usar FAL2; las transferencias, las claves de administrador y las acciones irreversibles ameritan una evaluación de FAL3. Las excepciones registran recurso, fecha límite, control compensatorio y propietario.

Despliegue por inquilino y recurso mientras compara finalización, recuperación, tickets de soporte y eventos de seguridad. Detenga el despliegue ante fallas de inyección de aserciones o de vinculación; no degrade silenciosamente las operaciones de alto riesgo a FAL1 por motivos de disponibilidad.

Respuesta modelo

Evaluaría IAL, AAL y FAL por separado. Utilice FAL1 para contenido de bajo riesgo, FAL2 para flujos de empleados y multi-IdP con defensas más sólidas contra inyecciones, y considere FAL3 para operaciones de alto valor como claves de administrador o transferencias irreversibles, diseñando los autenticadores vinculados y la recuperación desde el inicio.

Cada callback de OIDC valida emisor, audiencia, firma, tiempo y nonce, vinculando emisor, cliente, state, URI de redireccionamiento y transacción. JWKS proviene únicamente de emisores aprobados y rota con solapamiento. Despliegue por inquilino, monitoree inyección, reproducción, recuperación y finalización, y asigne a cada excepción una fecha límite y un control compensatorio. Los flujos de alto riesgo fallan cerrados (fail closed) durante interrupciones de verificación.

Errores comunes

• Tratar FAL como robustez de inicio de sesión e ignorar IAL y AAL.
• Asumir que OIDC significa automáticamente FAL2 o FAL3.
• Comprobar solo una firma, y no el emisor, la audiencia, el nonce, el tiempo de vida y el contexto de la transacción.
• Permitir que un emisor o un kid suministrado por el usuario active un descubrimiento o una obtención de claves arbitrarios.
• Afirmar que FAL3 es una sola configuración sin un diseño de autenticador vinculado y de recuperación.
• Fusionar reclamos de correo electrónico de diferentes IdPs en una sola identidad.
• Degradar silenciosamente operaciones de alto riesgo a FAL1 para mejorar la tasa de finalización.

Preguntas de seguimiento y respuestas

¿En qué se diferencia FAL2 de AAL2?

AAL2 describe la robustez del autenticador; FAL2 describe la protección de la entrega de aserciones de federación. Son independientes y deben registrarse y componerse por separado.

¿Cuándo vale la pena el costo de FAL3?

Para acciones de alto valor donde el riesgo de transferencia de aserciones importa y los usuarios pueden presentar una prueba de autenticador vinculado, como claves de administrador o transacciones irreversibles. El costo y la capacidad de recuperación deben evaluarse juntos.

¿Por qué sigue siendo importante el nonce?

El nonce vincula un ID Token a esta solicitud de autenticación y reduce la reproducción de una respuesta antigua. No reemplaza al emisor, la audiencia, la firma ni la política de FAL.

¿Qué ocurre si el JWKS de un IdP no está disponible?

Utilice una caché corta y controlada. Si no se puede verificar una aserción de alto riesgo, falle de forma cerrada (fail closed) y genere una alerta; nunca acepte una clave desconocida ni omita la verificación.

¿Cómo se maneja el reemplazo de un dispositivo?

FAL3 requiere una nueva vinculación y una ruta de recuperación aprobada. El inicio de sesión ordinario en el IdP puede ser un factor de recuperación, pero no puede heredar silenciosamente la vinculación del dispositivo antiguo.

¿Cómo explica la elección de FAL a los equipos de producto?

Explique el riesgo del recurso, las consecuencias de la transferencia de aserciones, la población de usuarios, el costo de recuperación y los requisitos de cumplimiento. Registre fechas límite, métricas y controles compensatorios en lugar de citar únicamente el nombre de un nivel.