El Trato Que Se Frenó en "¿Soportan SAML?"

Vi este escenario repetirse con más de un cliente. Un contrato empresarial prometedor avanza por el pipeline — la evaluación sale bien, el champion interno está convencido, compras ya está involucrado — y de golpe se frena en algo que no tiene nada que ver con el producto. Alguien del equipo de seguridad de IT del comprador completa un cuestionario de proveedores, llega a la línea que pregunta por "Single Sign-On (SAML 2.0 u OIDC)", y la respuesta honesta es "todavía no". El contrato no muere de inmediato. Se queda en silencio. Pasan semanas. Eventualmente alguien avisa, con cortesía, que se decidieron por un competidor que sí tenía esa casilla marcada.

Esto no es una hipótesis. Los reportes del sector ubican de forma consistente la falta de SSO entre las brechas más comunes que frenan ventas empresariales de SaaS, y cada vez aparece más como requisito base en lugar de funcionalidad premium — los compradores lo esperan incluido en el plan que ya están pagando, no como un upsell costoso aparte. Si vendés a cuentas de mercado medio o empresas grandes y tu plataforma todavía depende de usuario y contraseña, estás dejando ingresos sobre la mesa por motivos que no tienen nada que ver con las funcionalidades de tu producto.

Por Qué Esto No Es un Pedido de Feature — Es una Barrera de Compras

La razón por la que el SSO aparece tan temprano en las negociaciones empresariales es que en realidad no se trata de comodidad para el usuario final. Se trata de cómo el departamento de IT del comprador gestiona el riesgo de cada proveedor en su stack tecnológico.

Cuando una empresa estandariza su identidad en un proveedor — Okta, Microsoft Entra ID, Google Workspace, Ping Identity — cada aplicación conectada hereda automáticamente sus políticas de acceso. Si un empleado se va, IT desactiva una cuenta y el acceso a todas las apps conectadas desaparece con ella. Si exige MFA, se aplica en todos lados sin pedirle a cada proveedor que lo implemente por separado. Y cuando un auditor pregunta quién tuvo acceso y cuándo se revocó, la respuesta vive en un solo lugar, no dispersa entre decenas de paneles.

Un proveedor que no soporta SSO rompe ese modelo. Significa que el equipo de seguridad del comprador tiene que confiar en que tu aplicación aplica bien su propia política de contraseñas, su propio MFA y su propio proceso de baja de usuarios, siempre, sin fallar. Para una empresa que responde ante auditores de SOC 2 o aseguradoras de ciberseguridad, ese es un riesgo que prefieren no asumir, y no tener SSO es un motivo fácil para descalificar a un proveedor antes de siquiera hablar de precio.

Poniendo el Vocabulario en Orden

Recomiendo alinear a las partes técnicas y comerciales sobre algunos términos antes de dimensionar el trabajo, porque se usan con bastante soltura en ambas conversaciones:

  • SSO (Single Sign-On) es el resultado — un usuario inicia sesión una vez con la identidad de su empresa y accede sin una contraseña separada para tu app.
  • SAML 2.0 es el protocolo más antiguo, basado en XML, que la mayoría de los proveedores de identidad todavía usan por default. Es a lo que se refieren casi todos los cuestionarios de seguridad cuando preguntan si soportás SSO.
  • OIDC (OpenID Connect) es el protocolo moderno, basado en JSON/REST y construido sobre OAuth2. Es más simple de implementar y cada vez más preferido por proveedores nuevos, aunque no todos los compradores migraron todavía.
  • SCIM es un protocolo relacionado pero distinto, para aprovisionamiento y baja automática de usuarios — permite que un administrador agregue o quite un usuario en Okta y ese cambio se propague solo a tu aplicación.

En mi experiencia, los compradores piden "SSO" pero en realidad evalúan tres cosas: autenticación (SAML/OIDC), aprovisionamiento (SCIM) y registro de auditoría. Dimensionar un proyecto solo alrededor de SAML, sin contemplar SCIM y los logs de auditoría, es la razón más común por la que estos proyectos tardan más de lo planeado.

Construir vs. Comprar: La Decisión Que Realmente Importa

Acá es donde oriento a casi todos mis clientes hacia la misma respuesta, y suele sorprender a quienes asumen que "somos un equipo de desarrollo, deberíamos construirlo nosotros".

Construir soporte para SAML y OIDC desde cero significa hacerte cargo de la rotación de certificados, el manejo de desfasajes de reloj, las particularidades de cada proveedor (Okta, Entra ID y Ping Identity interpretan el estándar SAML de forma ligeramente distinta) y una matriz de pruebas contra cada IdP que tus clientes puedan usar. Vi equipos presupuestar un par de semanas para esto y terminar cerca de un trimestre apenas se topan con el primer cliente con una configuración de IdP no estándar.

La alternativa es una capa de middleware de identidad — WorkOS, la funcionalidad Organizations de Auth0, o plataformas similares — que se ubica entre tu aplicación y los proveedores de identidad de tus clientes. Te integrás una sola vez contra la API del middleware, y este se encarga de traducir el protocolo para cada IdP del otro lado. Para la mayoría de las plataformas B2B que todavía no llegaron a una escala considerable, esta es la decisión correcta:

  • Construí SAML/OIDC a medida solo si tenés requisitos de identidad muy particulares, ya tenés decenas de clientes empresariales firmados y esperando, o razones legales o de cumplimiento genuinas que te obligan a ser dueño del código de identidad directamente.
  • Usá una plataforma de middleware si tenés un puñado de prospectos empresariales pidiendo SSO ahora mismo y necesitás cerrar contratos en semanas, no en trimestres. Esta es la opción correcta por default para la mayoría de las empresas que leen esto.
  • Presupuestá con realismo en cualquiera de los dos casos. Incluso con una plataforma de middleware, planificá tiempo de ingeniería real de tu lado — lógica de sesión y de matching de usuarios, una interfaz de administración para conectar proveedores de identidad, y pruebas contra al menos dos configuraciones reales de IdP de clientes, no solo un sandbox.

Esta decisión se conecta con un patrón más amplio que desarrollo en mi artículo sobre integración de APIs personalizadas: las plataformas que hacen que la integración sea indolora valen la pena, porque el costo alternativo no es solo horas de ingeniería — son los contratos que se frenan mientras vos todavía estás construyendo.

Los Errores de Implementación Que Convierten una Semana en un Trimestre

Incluso con una buena elección de middleware, veo los mismos errores una y otra vez:

  • Tratar el SSO como si fuera de un solo tenant. Si tu plataforma sirve a múltiples organizaciones, que es lo normal en SaaS B2B, cada cliente conecta su propio proveedor de identidad de forma independiente. Un diseño que asume un solo proveedor de identidad para toda la app tiene que rehacerse antes de poder soportar a un segundo cliente empresarial — es la misma disciplina de multi-tenancy que importa al escalar un portal web B2B para volumen empresarial.
  • No tener un plan para el matching de cuentas. Los empleados nuevos aparecen en el proveedor de identidad antes de que nadie le avise a tu app. Necesitás una regla clara, normalmente aprovisionamiento just-in-time por dominio de email, para lo que pasa la primera vez que alguien inicia sesión vía SSO sin tener una cuenta existente.
  • Ignorar SCIM hasta que un cliente lo exija. La gestión manual de usuarios funciona bien para cinco personas. IT empresarial espera baja automática apenas alguien deja la empresa, y eso es una integración de SCIM, no de SSO.
  • Probar poco contra proveedores reales. Una integración SAML que funciona contra tu propio tenant de prueba de Okta puede romperse contra la configuración de Entra ID de un cliente con mapeos de claims personalizados. Probá contra al menos dos proveedores distintos antes de darlo por terminado.
  • No tener autoservicio para administradores. IT empresarial quiere configurar su propia conexión de SSO sin abrir un ticket de soporte. Construir aunque sea un flujo básico de configuración autoservicio evita que tu equipo se convierta en el cuello de botella para cada cliente empresarial nuevo.

Por Dónde Empezaría

Si te está llegando la primera pregunta de si tu plataforma soporta SSO de parte de un prospecto, no te desesperes ni sobredimensiones el trabajo. Empezá por identificar qué dos o tres proveedores de identidad usan realmente tus prospectos activos, evaluá una plataforma de middleware contra esos proveedores, y llevá a producción una conexión SAML/OIDC funcional con tu primer cliente empresarial real antes de construir algo más elaborado. El objetivo no es una arquitectura de identidad perfecta — es sacarte de encima la única línea del cuestionario que hoy te está costando contratos.

Hablemos de su situación.