Resumen
WebAuthn, FIDO2, OIDC, SAML y SCIM aparecen a menudo en la misma arquitectura de acceso, pero resuelven problemas distintos en capas distintas. Confundirlos deja brechas: una aplicación puede tener SSO sin autenticación resistente al phishing, desactivación SCIM sin terminar sesiones o una passkey en el IdP aunque la aplicación destino no conozca WebAuthn.
Una arquitectura madura combina las capas. WebAuthn y FIDO2 regulan cómo se autentica una cuenta. OIDC o SAML transmiten el resultado de autenticación y claims a una aplicación. SCIM crea y actualiza recursos de identidad. La aplicación sigue aplicando autorización y administrando sus sesiones.
Cada estándar en una frase
| Estándar | Capa | Qué hace | Qué no hace |
|---|---|---|---|
| WebAuthn | API entre la parte de confianza y la plataforma cliente | Registra y verifica credenciales de clave pública vinculadas a una parte de confianza | No define federación, aprovisionamiento, autorización de aplicación ni gestión general de sesiones |
| FIDO2 | Familia de estándares | Combina WebAuthn con CTAP entre plataforma cliente y autenticador externo | No es un protocolo de federación o aprovisionamiento ni un elemento de interfaz |
| OpenID Connect | Autenticación federada | Añade a OAuth 2.0 una capa de identidad para verificar un evento y claims mediante un ID Token | No prescribe cómo el proveedor autentica al usuario ni aprovisiona la cuenta de aplicación |
| SAML 2.0 | Federación y SSO web | Transporta autenticación, atributos y seguridad mediante assertions XML y mensajes de protocolo | No realiza la autenticación previa del usuario ni aprovisiona la cuenta |
| SCIM 2.0 | Ciclo de vida de identidad | Administra usuarios, grupos y datos de identidad mediante recursos HTTP y esquemas | No autentica usuarios finales, define autorización de aplicación ni garantiza terminar sesiones activas |
Cómo trabajan juntas las capas
- 1. Aprovisionar la cuenta. Un cliente SCIM crea o actualiza la cuenta y los grupos en la aplicación destino si admite las operaciones y atributos necesarios.
- 2. Iniciar el acceso. El usuario abre la aplicación, que delega la autenticación en un IdP confiable.
- 3. Iniciar la federación. La aplicación envía una solicitud de autorización OIDC o de autenticación SAML según el perfil admitido.
- 4. Autenticar en el IdP. El IdP puede usar WebAuthn/FIDO2 para verificar una assertion nueva vinculada a la parte de confianza. Las passkeys vinculadas permanecen en un autenticador; las sincronizadas pueden replicar material protegido mediante el proveedor.
- 5. Validar la respuesta. La aplicación valida ID Token o respuesta SAML, incluido emisor, audiencia, firma, tiempo, correlación con la solicitud y demás requisitos.
- 6. Crear la sesión. La aplicación asigna subject y claims a una cuenta local, autoriza y emite su propia sesión. Duración, revocación y logout siguen siendo responsabilidad de la aplicación.
- 7. Procesar cambios. SCIM puede desactivar o modificar la cuenta; retirar permisos y terminar sesiones activas debe verificarse por separado.
Dónde encaja cada estándar
- Autenticación: WebAuthn y FIDO2. El autenticador firma un desafío nuevo para la parte de confianza. WebAuthn transporta RP ID y origen; CTAP conecta la plataforma con autenticadores externos. La clave privada no se envía a la parte de confianza.
- Federación: OIDC o SAML. Ambos permiten que una aplicación confíe en un evento de autenticación del IdP. OIDC es habitual en aplicaciones web modernas y nativas; SAML en SSO web empresarial. Tras la compatibilidad, importan el perfil, los controles y la calidad de implementación.
- Automatización del ciclo de vida: SCIM. SCIM estandariza operaciones HTTP y esquemas para usuarios y grupos. Reduce trabajo manual, pero hay que validar mapeos, aplicación de cambios, reintentos, fallos parciales y fin de sesión.
Errores frecuentes antes del despliegue
- Tratar SSO como prueba de autenticación fuerte. OIDC o SAML pueden federar autenticación débil o fuerte. Exige y valida el nivel de garantía adecuado.
- Usar OAuth 2.0 por sí solo como identidad. OAuth es un marco de autorización. OpenID Connect añade semántica de autenticación, ID Token y claims de identidad.
- Suponer que el soporte FIDO2 es binario. Una aplicación puede admitir WebAuthn directamente, solo mediante un IdP o no admitirlo. Prueba la ruta completa por aplicación.
- Suponer que una passkey sincronizada nunca sale de un dispositivo. Las credenciales vinculadas permanecen en un autenticador; las passkeys sincronizadas replican deliberadamente material protegido mediante un proveedor.
- Suponer que SCIM termina sesiones. Desactivar un registro de usuario no garantiza la revocación inmediata de cookies o tokens existentes.
- Elegir SAML u OIDC solo por marca. Tras comprobar compatibilidad, evalúa flujo, perfil, redirects, audiencia, firmas, cifrado, rotación, claims, logout y sesiones.
Qué evaluar
- Fuerza de autenticación. Métodos permitidos, aplicación de resistencia al phishing y transmisión o solicitud del contexto de autenticación.
- Cobertura de federación. Qué aplicaciones admiten OIDC, SAML, ambos o ninguno y qué flujos, bindings, perfiles, algoritmos y logout implementan.
- Correlación de identidad. Cómo identifiers estables, NameID, correo y reglas de enlace evitan cuentas duplicadas o mal vinculadas.
- Claims y atributos. Qué datos se comparten, minimizan, transforman, firman, cifran y usan para autorizar.
- Aprovisionamiento. Recursos y operaciones SCIM, mapeos de grupos y permisos, reintentos, fallos parciales y tiempo de desactivación.
- Sesiones y auditoría. Cómo se crean, renuevan, revocan y terminan las sesiones, y si se pueden correlacionar registro, autenticación, federación, aprovisionamiento y revocación.
Aplicación en Gideon Identity
Gideon Identity usa WebAuthn y FIDO2 para autenticación resistente al phishing, admite federación OIDC y SAML para aplicaciones compatibles y utiliza SCIM, cuando está disponible, para automatizar cambios del ciclo de vida. El despliegue concreto depende de las capacidades, mapeos y controles de sesión de cada aplicación.
Lecturas relacionadas
- Empieza con Passkeys para la identidad de la fuerza laboral: guía de compra.
- Compara controles de credencial, dispositivo y sesión en Autenticación vinculada al dispositivo frente a MFA convencional.
- Revisa la evidencia de ciclo de vida en Trusted Authenticator Lineage.
- Entiende la protección de claves de plataforma en Cómo Secure Enclave y TPM cambian el acceso de la fuerza laboral.
- Descubre Gideon Identity.
Fuentes primarias
- FIDO Alliance describe FIDO2 y los modelos de passkeys en su documentación de passkeys.
- OpenID Foundation define OIDC en OpenID Connect Core 1.0.
- OASIS define SAML en SAML 2.0 Technical Overview.
- IETF define SCIM en RFC 7644.
Cómo usar este recurso
Asigna cada requisito a la capa correcta, inventaría las capacidades de las aplicaciones y define criterios medibles para autenticación, federación, aprovisionamiento, autorización y ciclo de vida de sesión.