OIDC o SAML: cuál necesitas en realidad

Todo equipo que construye software B2B llega a la misma bifurcación la primera vez que un cliente serio dice «necesitamos SSO». Dos siglas, OIDC y SAML, ambas afirmando ser la respuesta, y un internet lleno de tablas comparativas que te dicen que SAML es «empresarial» y OIDC es «moderno» y te dejan exactamente tan atascado como antes. Aquí está la versión que de verdad te ayuda a lanzar.

Qué son

SAML es de 2005 y es XML. Un proveedor de identidad firma una aserción («esta es alice@bigco.com, estos son sus grupos») y la envía a tu aplicación, que verifica la firma e inicia su sesión. Se diseñó para el navegador y para la identidad de los empleados, en una época en la que «la empresa» significaba Active Directory on-premise y una pila SOAP. Es verboso, es viejo y está absolutamente en todas partes dentro de las grandes organizaciones, que es el único dato sobre él que te importa.

OIDC es de 2014 y es JSON y JWT, construido sobre OAuth 2.0. Un proveedor de identidad emite un token de ID que tu aplicación valida. Se diseñó para la web moderna: SPA, aplicaciones móviles, APIs, inicio de sesión social. Es más limpio, está mejor especificado para las cosas que realmente construyes hoy y es el protocolo que hoy habla la mayoría de la identidad nueva.

Cuándo gana cada uno

La respuesta honesta a «cuál debería construir» es que casi nunca te toca elegir. Construyes el que eligió el departamento de TI de tu cliente, y lo eligieron mucho antes de haber oído hablar de ti.

• Un cliente en Okta, Entra ID o Google Workspace suele poder usar cualquiera de los dos, y OIDC es el camino más agradable.
• Un cliente con un ADFS antiguo, un IdP heredado on-premise o una lista de requisitos de adquisiciones escrita en 2016 te entregará un fragmento de metadatos SAML y una invitación de calendario, y ahí se acaba la discusión.
• Tus aplicaciones de primera parte, tu panel y tu cliente móvil, quieren OIDC, y punto. Jamás recurrirías a SAML para iniciar la sesión de un usuario en tu propia aplicación React.

Así que el campo se divide con claridad: OIDC para lo moderno y lo propio, SAML para «porque la empresa lo dijo». Vende a suficientes empresas y te pedirán ambos. No con el tiempo. Una y otra vez.

Las trampas, que es donde construirlo tú mismo se vuelve caro

El problema de SAML es que es un protocolo de XML firmado, y el XML firmado es una de las cosas más fiablemente peligrosas de la criptografía aplicada. Las formas de equivocarse en la verificación de la firma SAML son muchas y famosas:

• Envoltura de firma (XSW): un atacante mueve el elemento firmado e introduce una aserción falsificada y sin firmar donde tu analizador realmente lee. Si verificas la firma y lees la aserción como dos pasos separados, probablemente seas vulnerable, y casi toda primera implementación hace exactamente eso.
• Canonicalización e inyección de comentarios: la clase de errores de 2018 en la que user@company.com<!---->.evil.com se canonicaliza de una forma para la verificación de la firma y de otra para la cadena que lee tu código, así que autenticas alegremente a la persona equivocada. CVEs reales, en varias bibliotecas importantes.
• Las más silenciosas: firmar la respuesta pero no la aserción, aceptar aserciones sin firmar, confiar en el emisor que proporciona el IdP sin fijarlo, equivocarse en la ventana de validez de la aserción. Cada una es su propia trampa, y cada una la han llevado a producción personas que sabían lo que hacían.

OIDC es considerablemente más sensato, pero no está libre de aristas. Aún tienes que validar los claims correctos (iss, aud, exp, el nonce), usar PKCE, rechazar el flujo implícito hace tiempo muerto, y rotar y cachear JWKS sin rechazar un token firmado por una clave que aún no has obtenido. La diferencia es que las trampas de OIDC están documentadas, tienen forma de JSON y la mayoría de las bibliotecas las manejan correctamente por defecto. Las trampas de SAML tienen forma de XML y se han comido a equipos de seguridad con muchos más recursos que el tuyo.

La respuesta real

«OIDC o SAML» es la pregunta equivocada, porque la respuesta correcta para un producto B2B es «sí». Tus clientes modernos y tus propias aplicaciones quieren OIDC. Tus clientes empresariales exigirán SAML en un calendario que no controlas. Construye para uno, y la tercera llamada de ventas lo rompe.

Lo que realmente necesitas es una forma de aceptar cualquier protocolo que traiga cada cliente, sin levantar dos pilas, dos conjuntos de fontanería de metadatos y dos oportunidades independientes de equivocarte en la verificación de la firma. La implementación es el coste. Elegir nunca fue la parte difícil.

Esa es la parte que Authagonal te quita de encima. Cada tenant obtiene SAML 2.0 con importación de metadatos en un clic y federación OIDC con los proveedores que tus clientes ya usan, en el mismo inicio de sesión, sin tarifa por conexión para ninguno de los dos. No implementas la verificación de firma XML, no haces de niñera de una caché de JWKS y no reconstruyes nada de eso cuando el siguiente cliente aparece hablando el otro protocolo. Mira lo que está incluido.