SCIM y SSO para herramientas de marketing: lo que realmente pide el TI empresarial

El requisito de SSO/SCIM llega de dos maneras. A veces aparece incrustado en un cuestionario de seguridad: "¿Su aplicación admite inicio de sesión único SAML 2.0 u OIDC? ¿Admite aprovisionamiento automatizado SCIM 2.0?". A veces llega como una instrucción directa de TI: cualquier proveedor que maneje datos personales debe autenticarse a través del IdP corporativo. Sin inicio de sesión independiente con contraseña, sin credenciales compartidas, sin excepciones.

En cualquier caso, la consecuencia es la misma. Su herramienta de marketing o se integra con el proveedor de identidad de la empresa o es reemplazada.

Las herramientas de marketing -acortadores de URL, rastreadores de campañas, gestores de UTM- están llegando a esta revisión ahora porque los equipos de marketing manejan PII en la capa de eventos de clic. Un enlace corto que registra la IP, el user-agent y el referrer de un usuario está procesando datos personales. Ese procesamiento pertenece al modelo de acceso gobernado por el IdP.

Esta publicación es la versión checklist de adquisiciones: qué requieren SSO y SCIM, dónde se queda corto el SaaS de marketing y las cinco preguntas que llevar a la llamada de descubrimiento del proveedor.

TL;DR#

• SAML 2.0 y OIDC sirven a diferentes generaciones de IdP - la empresa legacy ejecuta SAML; los IdP modernos hablan OIDC de forma nativa. Un proveedor que solo admita uno está perdiendo la mitad del mercado.
• SCIM 2.0 es la capa de aprovisionamiento: crea cuentas, las actualiza y -fundamentalmente- las desaprovisiona. El aprovisionamiento JIT crea cuentas en el primer inicio de sesión pero no desaprovisiona. Para auditoría, SCIM es el requisito.
• La mayoría de las herramientas de marketing limitan el SSO detrás de un nivel enterprise con un precio de 500-2.000 $/mes por encima del plan base. Los proveedores que incluyen SSO en un nivel Business sin el sobrecoste son la excepción.
• Las preguntas de adquisición que importan: URL de metadatos SAML, URL del endpoint SCIM, cadencia de rotación de bearer token, latencia de desaprovisionamiento y mapeo de grupo de IdP a rol.

SAML 2.0 y OIDC: por qué ambos siguen existiendo#

SAML 2.0, publicado por OASIS en 2005, es un estándar de federación basado en XML. El IdP publica una SAML Response firmada en la URL del Assertion Consumer Service del SP; el SP valida la firma contra el certificado del IdP, extrae las declaraciones de sujeto y atributos, y crea una sesión.

OIDC, construido sobre OAuth 2.0, maneja el mismo trabajo con JSON. El IdP emite un JWT (el ID token) que el SP verifica contra el endpoint JWKS del IdP.

Ambos coexisten porque los IdP empresariales legacy -AD FS on-premises, configuraciones antiguas de Okta, Ping Federate- son principalmente SAML. Los IdP cloud-native como Google Workspace y el stack moderno de JumpCloud hablan OIDC de forma nativa y llevan SAML como protocolo secundario. Las empresas mixtas ejecutan ambos.

Flujo SP-initiated vs IdP-initiated. El inicio de sesión SP-initiated es el estándar: el usuario visita la app, la app redirige al IdP, el IdP autentica y publica de vuelta. IdP-initiated salta la redirección del SP - el usuario hace clic en un mosaico del panel de Okta o Entra y el IdP envía una aserción no solicitada directamente al SP. Ambos flujos deben funcionar. IdP-initiated es más difícil de implementar de forma segura (riesgo de inyección estilo CSRF si el SP no valida los atributos de binding y destination) y los proveedores que solo admiten SP-initiated fallarán cuando TI intente añadir el mosaico de la app al panel de la empresa.

SCIM 2.0: la capa de aprovisionamiento#

SCIM 2.0 - RFC 7644 - automatiza la gestión del ciclo de vida de cuentas de usuario en aplicaciones SaaS. Tres operaciones principales:

Aprovisionamiento: POST /Users con los atributos del usuario. El SP crea la cuenta y devuelve el nuevo ID.

Actualizaciones: PATCH /Users/:id con un payload JSON Patch - nombre para mostrar, departamento, rol, cualquier cosa para la que el IdP sea autoritativo.

Desaprovisionamiento: DELETE /Users/:id (eliminación dura) o PATCH /Users/:id con { "active": false } (desactivación suave, el patrón empresarial más común).

El desaprovisionamiento es la pieza crítica para auditoría. Las cuentas huérfanas -cuentas pertenecientes a ex-empleados que nunca se cerraron porque TI lo olvidó, o porque el proveedor no admite desaprovisionamiento automatizado- son una superficie de brecha constante. El control A.9.2 de ISO 27001 y CC6.2 de SOC 2 requieren ambos un proceso documentado para eliminar accesos. El desaprovisionamiento manual falla de forma predecible: el ticket de offboarding se pierde, la cuenta permanece activa. SCIM hace que el desaprovisionamiento sea automático y auditable: el IdP dispara la solicitud de desactivación, el SP la registra, y ese registro es el artefacto de auditoría.

La brecha de las herramientas de marketing#

La mayoría de las categorías SaaS empresariales -RR. HH., CRM, ITSM, hosting de código- envían SSO en planes que un equipo del mercado medio realmente puede comprar. Las herramientas de marketing han sido más lentas. El patrón que veo de forma constante: SSO aparece listado como una característica "Enterprise", con un precio en un nivel separado que cuesta 500-2.000 $/mes por encima del plan Business. La implicación es que SSO es un upsell de lujo para grandes organizaciones, no un control de seguridad básico.

Ese encuadre es cada vez más incompatible con la forma en que el TI empresarial evalúa a los proveedores. Cuando una herramienta de marketing maneja datos de clic sobre usuarios identificables, está dentro del alcance del programa de gobernanza de acceso de la empresa independientemente de la categoría. Limitar el SSO detrás de un nivel premium significa que el equipo de marketing opera la herramienta fuera del IdP - el resultado que TI intenta evitar.

Los proveedores que incluyen SSO en el nivel Business sin un sobrecoste separado son la excepción. Entre los acortadores de URL: Elido incluye SSO SAML/OIDC y aprovisionamiento SCIM en el plan Business a través de WorkOS. Bl.ink incluye SSO en su plan Team. Loops (automatización de email) y Customer.io ambos envían SSO en Business sin una puerta enterprise separada.

Cuando un proveedor lista SSO solo bajo "Contactar ventas para precios Enterprise", está mirando un flujo de desaprovisionamiento manual para cada transición de empleado, durante todo el tiempo que esa herramienta esté en el stack.

Panorama de IdP y compatibilidad#

Seis IdP dominan el TI empresarial:

Okta es el IdP cloud más común en empresas estadounidenses. Okta envía SAML 2.0, OIDC y una interfaz SCIM pulida. Un proveedor listado en la Okta Integration Network con SCIM confirmado significa que la configuración del equipo de TI está documentada y probada; de lo contrario, están escribiendo una integración personalizada.

Microsoft Entra ID (anteriormente Azure AD) es el predeterminado para tiendas de Microsoft 365. Su agente de aprovisionamiento SCIM consulta el endpoint de la aplicación - el intervalo predeterminado es 40 minutos, por lo que el desaprovisionamiento no es instantáneo. Vale la pena sacarlo a relucir en la revisión de adquisiciones.

JumpCloud admite SAML 2.0, OIDC y SCIM 2.0. Popular entre equipos del mercado medio que quieren un directorio en la nube sin AD on-premises.

Google Workspace usa OIDC de forma nativa; SAML 2.0 está disponible para compatibilidad con aplicaciones legacy. Las integraciones SCIM de terceros siguen la ruta estándar del RFC 7644.

OneLogin mantiene SAML 2.0, OIDC y SCIM. Común en organizaciones del mercado medio que se estandarizaron antes de la consolidación del mercado por parte de Okta.

WorkOS es una plataforma del lado del proveedor (no un IdP de usuario final) que las aplicaciones SaaS usan para implementar SSO y SCIM. Un proveedor que dice "usamos WorkOS" está expresando compatibilidad con Okta, Entra, JumpCloud, Google y OneLogin simultáneamente. La integración SSO de Elido está construida sobre WorkOS. La implicación práctica para TI: si puedes apuntar Okta o Entra a un endpoint SCIM, la integración funciona sin trabajo de configuración específico del proveedor.

Aprovisionamiento JIT vs aprovisionamiento SCIM#

El aprovisionamiento Just-in-Time crea una cuenta de usuario la primera vez que el usuario se autentica a través de SSO. No se requiere paso de preaprovisionamiento; los atributos vienen de la aserción SAML o el token OIDC.

JIT resuelve la mitad del aprovisionamiento de forma limpia. La mitad del desaprovisionamiento es el problema. Cuando el usuario es eliminado del IdP, su sesión SSO deja de funcionar - pero la cuenta en la aplicación SaaS persiste. Los tokens API de larga duración pueden seguir funcionando. La cuenta aparece en cualquier auditoría de usuarios activos.

Para entornos ISO 27001 o SOC 2, JIT por sí solo es insuficiente. La pregunta de auditoría no es "¿puede este empleado iniciar sesión?" sino "¿existe un registro auditable de que el acceso fue terminado?". JIT no genera ese registro. SCIM sí: el evento DELETE o { "active": false } se registra tanto en el IdP como en el SP, con marca de tiempo y consultable.

Si su revisión de proveedor requiere evidencia de desaprovisionamiento, pregunte específicamente si se admite el desaprovisionamiento SCIM 2.0. Un proveedor que responde "sí, admitimos SSO" cuando la pregunta era sobre SCIM está respondiendo a una pregunta diferente.

Mapeo de roles: grupo de IdP a rol SaaS#

El patrón estándar: el IdP tiene dos grupos - marketing-team (todo el personal) y marketing-leads (líderes de equipo). La aplicación SaaS tiene dos roles: Marketer y Admin. El equipo de TI configura el mapeo una vez: marketing-team → Marketer, marketing-leads → Admin. Cuando alguien cambia entre grupos, la siguiente sincronización SCIM actualiza su rol automáticamente.

SCIM lleva la pertenencia a grupo a través del recurso Groups (GET /Groups, POST /Groups, PATCH /Groups/:id). No todas las implementaciones SCIM admiten sincronización de grupos - algunos proveedores implementan solo el aprovisionamiento de usuarios, lo que significa que el mapeo de roles todavía requiere configuración manual por usuario. Pregunte al proveedor específicamente si se admite el push de grupos SCIM y si el mapeo de roles es configurable por el administrador sin un ticket de soporte.

Para organizaciones con sede en la UE, los datos de pertenencia a grupos de IdP que fluyen a través de SCIM pueden constituir por sí mismos datos personales bajo el artículo 4(1) del GDPR. La publicación sobre residencia de datos de la UE para marketing cubre lo que su DPA debe decir sobre la capa de datos de identidad. Su proveedor SaaS es un procesador para esos datos, y el DPA debe abordarlo explícitamente.

Qué preguntar en adquisiciones#

Cinco preguntas que determinan si la integración SSO/SCIM de una herramienta de marketing es medio día de configuración de TI o un proyecto de varias semanas:

URL de metadatos SAML. ¿Puede el proveedor suministrar una URL estática que apunte a sus metadatos SP (entity ID, ACS URL, certificado de firma)? Esto es lo que pegas en Okta o Entra. La entrada manual de metadatos por cliente es una señal de alarma.

Endpoint SCIM y método de autenticación. ¿Cuál es la URL base de SCIM? Bearer token es el estándar; OAuth 2.0 client credentials es más complejo. ¿Cuál es la cadencia de rotación del token? Un token estático que nunca rota es una responsabilidad.

Latencia de desaprovisionamiento. Cuando el IdP envía PATCH /Users/:id { "active": false } o DELETE, ¿con qué rapidez se termina el acceso? El intervalo de aprovisionamiento de Entra por defecto es de 40 minutos en el lado del IdP. El proveedor debe comprometerse a una ventana de procesamiento una vez que llegue la solicitud. La combinación de ambas latencias es lo que preguntará su auditor SOC 2.

Soporte de push de grupos. El push de grupos SCIM es independiente del aprovisionamiento de usuarios SCIM. Si el proveedor solo implementa sincronización de usuarios, el mapeo de roles requiere configuración manual por usuario. Pregunte específicamente.

Soporte de mosaico IdP. ¿Puede la aplicación añadirse como un mosaico en el panel de Okta o Entra y admitir inicio de sesión IdP-initiated?

La capa de cumplimiento#

El control A.9.2 del Anexo A de ISO 27001 requiere que los derechos de acceso de usuario se otorguen, revisen y terminen según un proceso documentado. A.9.3 requiere que los usuarios se autentiquen solo con credenciales asignadas a ellos. SCIM es el mecanismo operativo que conecta "offboarding de RR. HH." con "acceso SaaS revocado" sin pasos manuales.

CC6.2 de SOC 2 requiere que las entidades registren y autoricen a los usuarios antes de otorgar acceso. CC6.3 requiere revisión periódica de acceso y eliminación. El registro de desaprovisionamiento SCIM -un registro con marca de tiempo de cuándo el IdP instruyó a la aplicación SaaS para desactivar o eliminar un usuario- es el artefacto de auditoría que demuestra el cumplimiento de CC6.3 para cada aplicación dentro del alcance.

Elido está certificado ISO 27001. SOC 2 Type II está en progreso, objetivo H2 2026. La postura de identidad -SAML/OIDC a través de WorkOS, desaprovisionamiento SCIM 2.0, mapeo de roles basado en grupos- está documentada en la página de confianza y el resumen de solutions/enterprise. Los BAA están disponibles en el plan Business para flujos de trabajo adyacentes a HIPAA.

La cornerstone de GDPR para acortadores de URL cubre el artículo 28 y el artículo 32 en su totalidad. SSO y SCIM son los controles técnicos del artículo 32 -autenticación a través de SSO, desaprovisionamiento a través de SCIM- no características independientes. Son componentes de la postura de seguridad que su DPO evalúa durante la revisión del artículo 32.

/pricing muestra el desglose del plan y dónde aparecen SSO/SCIM. /solutions/compliance es el resumen orientado al equipo de compra. La conversación sobre evidencia de desaprovisionamiento pertenece a la misma llamada de adquisiciones que el DPA, la lista de subprocesadores y el compromiso de residencia de datos - esas son las preguntas que determinan si una herramienta de marketing pasa la revisión de seguridad.

NIST SP 800-63-3 Digital Identity Guidelines, consultado el 12-05-2026, es el marco autoritativo para los niveles de garantía y tipos de autenticadores que sustenta muchos requisitos de políticas de IdP empresarial. La sección de federación -800-63C- es directamente relevante para la configuración de integración SAML y OIDC.