SCIM e SSO para ferramentas de marketing: o que a TI empresarial realmente pergunta

O requisito de SSO/SCIM chega de duas formas. Por vezes vem integrado num questionário de segurança: "A sua aplicação suporta single sign-on SAML 2.0 ou OIDC? Suporta provisionamento automatizado SCIM 2.0?" Por vezes chega como instrução direta da TI: qualquer fornecedor que trate dados pessoais tem de autenticar através do IdP corporativo. Sem login com palavra-passe independente, sem credenciais partilhadas, sem exceções.

Em qualquer caso, a consequência é a mesma. A sua ferramenta de marketing ou se integra com o fornecedor de identidade da empresa, ou é substituída.

As ferramentas de marketing - encurtadores de URL, rastreadores de campanha, gestores de UTM - estão a chegar a esta revisão agora porque as equipas de marketing gerem PII na camada de eventos de clique. Uma hiperligação curta que regista o IP do utilizador, o user-agent e o referrer está a processar dados pessoais. Esse processamento pertence ao modelo de controlo de acesso governado pelo IdP.

Este artigo é a versão da lista de verificação de procurement: o que o SSO e o SCIM requerem, onde o SaaS de marketing fica aquém, e as cinco perguntas a levar para a chamada de descoberta com o fornecedor.

TL;DR#

• SAML 2.0 e OIDC servem gerações diferentes de IdP - o enterprise legado usa SAML; os IdPs modernos falam OIDC nativamente. Um fornecedor que suporta apenas um deles está a perder metade do mercado.
• SCIM 2.0 é a camada de provisionamento: cria contas, atualiza-as e - criticamente - deprovisionam-nas. O provisionamento JIT cria contas no primeiro login, mas não deprovisionam. Para auditoria, o SCIM é o requisito.
• A maioria das ferramentas de marketing coloca o SSO atrás de um tier empresarial com um preço de 500–2.000 dólares por mês acima do plano base. Os fornecedores que incluem o SSO no tier Business sem esse custo adicional são a exceção.
• As perguntas de procurement que importam: URL de metadados SAML, URL do endpoint SCIM, cadência de rotação do bearer token, latência de desprovisionamento e mapeamento de grupo IdP para função.

SAML 2.0 e OIDC: por que ambos ainda existem#

O SAML 2.0, publicado pela OASIS em 2005, é um padrão de federação baseado em XML. O IdP publica uma SAML Response assinada no URL do Assertion Consumer Service do SP; o SP valida a assinatura face ao certificado do IdP, extrai o sujeito e as declarações de atributos, e cria uma sessão.

O OIDC, construído sobre OAuth 2.0, trata o mesmo trabalho com JSON. O IdP emite um JWT (o ID token) que o SP verifica face ao endpoint JWKS do IdP.

Ambos coexistem porque os IdPs empresariais legados - AD FS on-premises, configurações mais antigas de Okta, Ping Federate - são de SAML-primary. IdPs nativos da cloud como Google Workspace e a stack moderna do JumpCloud falam OIDC nativamente e transportam SAML como protocolo secundário. As empresas mistas usam ambos.

Fluxo iniciado pelo SP vs. iniciado pelo IdP. O login iniciado pelo SP é o padrão: o utilizador visita a aplicação, a aplicação redireciona para o IdP, o IdP autentica e responde. O iniciado pelo IdP salta o redirecionamento do SP - o utilizador clica num tile no painel Okta ou Entra e o IdP envia uma asserção não solicitada diretamente para o SP. Ambos os fluxos têm de funcionar. O iniciado pelo IdP é mais difícil de implementar de forma segura (risco de injeção do tipo CSRF se o SP não validar os atributos de binding e destino) e os fornecedores que suportam apenas o iniciado pelo SP falharão quando a TI tentar adicionar o tile da aplicação ao painel da empresa.

SCIM 2.0: a camada de provisionamento#

O SCIM 2.0 - RFC 7644 - automatiza a gestão do ciclo de vida de contas de utilizador em aplicações SaaS. Três operações principais:

Provisionamento: POST /Users com os atributos do utilizador. O SP cria a conta e devolve o novo ID.

Atualizações: PATCH /Users/:id com um payload JSON Patch - nome de exibição, departamento, função, o que quer que o IdP seja autoritativo.

Desprovisionamento: DELETE /Users/:id (exclusão total) ou PATCH /Users/:id com { "active": false } (desativação suave, o padrão empresarial mais comum).

O desprovisionamento é a peça crítica para auditoria. Contas órfãs - contas pertencentes a ex-funcionários que nunca foram encerradas porque a TI esqueceu, ou porque o fornecedor não suporta desprovisionamento automatizado - são uma superfície de violação consistente. O controlo A.9.2 da ISO 27001 e o SOC 2 CC6.2 exigem ambos um processo documentado para remoção de acessos. O desprovisionamento manual falha previsivelmente: o ticket de offboarding é esquecido, a conta fica ativa. O SCIM torna o desprovisionamento automático e auditável - o IdP dispara o pedido de desativação, o SP regista-o, e esse registo é o artefacto de auditoria.

A lacuna das ferramentas de marketing#

A maioria das categorias de SaaS empresarial - RH, CRM, ITSM, alojamento de código - inclui SSO em planos que uma equipa de mercado médio pode efetivamente comprar. As ferramentas de marketing têm sido mais lentas. O padrão que vejo consistentemente: o SSO está listado como funcionalidade "Enterprise", com um preço num tier separado que custa 500–2.000 dólares por mês acima do plano Business. A implicação é que o SSO é um upsell de luxo para grandes organizações, não um controlo de segurança de base.

Este enquadramento é cada vez mais incompatível com a forma como a TI empresarial avalia fornecedores. Quando uma ferramenta de marketing trata dados de cliques de utilizadores identificáveis, está no âmbito do programa de governança de acessos da empresa, independentemente da categoria. Colocar o SSO atrás de um tier premium significa que a equipa de marketing opera a ferramenta fora do IdP - o resultado que a TI está a tentar evitar.

Os fornecedores que incluem SSO no tier Business sem um custo adicional separado são a exceção. Entre os encurtadores de URL: o Elido inclui SSO SAML/OIDC e provisionamento SCIM no plano Business via WorkOS. O Bl.ink inclui SSO no seu plano Team. O Loops (automação de email) e o Customer.io incluem ambos SSO no Business sem uma porta de acesso empresarial separada.

Quando um fornecedor lista o SSO apenas em "Contacte vendas para preços Enterprise", está a olhar para um fluxo de desprovisionamento manual para cada transição de funcionário, enquanto essa ferramenta estiver no stack.

Paisagem e compatibilidade de IdP#

Seis IdPs dominam a TI empresarial:

Okta é o IdP de cloud mais comum no enterprise dos EUA. O Okta inclui SAML 2.0, OIDC e uma interface SCIM bem trabalhada. Um fornecedor listado na Okta Integration Network com SCIM confirmado significa que a configuração da equipa de TI está documentada e testada; caso contrário, estão a escrever uma integração personalizada.

Microsoft Entra ID (anteriormente Azure AD) é o padrão para as lojas Microsoft 365. O seu agente de provisionamento SCIM faz polling ao endpoint da aplicação - o intervalo padrão é de 40 minutos, pelo que o desprovisionamento não é instantâneo. Vale a pena mencionar na revisão de procurement.

JumpCloud suporta SAML 2.0, OIDC e SCIM 2.0. Popular em equipas de mercado médio que querem um diretório na cloud sem AD on-premises.

Google Workspace usa OIDC nativamente; o SAML 2.0 está disponível para compatibilidade com aplicações legadas. As integrações SCIM de terceiros seguem o caminho padrão RFC 7644.

OneLogin mantém SAML 2.0, OIDC e SCIM. Comum em organizações de mercado médio que padronizaram antes da consolidação de mercado da Okta.

WorkOS é uma plataforma do lado do fornecedor (não um IdP de utilizador final) que as aplicações SaaS usam para implementar SSO e SCIM. Um fornecedor que diz "usamos WorkOS" está a expressar compatibilidade com Okta, Entra, JumpCloud, Google e OneLogin simultaneamente. A integração SSO do Elido é construída sobre WorkOS. A implicação prática para a TI: se conseguir apontar o Okta ou o Entra para um endpoint SCIM, a integração funciona sem trabalho de configuração específico do fornecedor.

Provisionamento JIT vs. provisionamento SCIM#

O provisionamento Just-in-Time cria uma conta de utilizador na primeira vez que o utilizador se autentica via SSO. Não é necessário um passo de pré-provisionamento; os atributos vêm da asserção SAML ou do token OIDC.

O JIT resolve a metade do provisionamento de forma limpa. A metade do desprovisionamento é o problema. Quando o utilizador é removido do IdP, a sua sessão SSO deixa de funcionar - mas a conta na aplicação SaaS persiste. Tokens de API de longa duração podem ainda funcionar. A conta aparece em qualquer auditoria de utilizadores ativos.

Para ambientes ISO 27001 ou SOC 2, o JIT sozinho é insuficiente. A questão de auditoria não é "este funcionário consegue fazer login?" mas "existe um registo auditável de que o acesso foi encerrado?". O JIT não gera esse registo. O SCIM gera: o evento DELETE ou { "active": false } é registado tanto no IdP como no SP, com timestamp, e é pesquisável.

Se a sua revisão de fornecedor requer evidências de desprovisionamento, pergunte especificamente se o desprovisionamento SCIM 2.0 é suportado. Um fornecedor que responde "sim, suportamos SSO" quando a pergunta era sobre SCIM está a responder a uma pergunta diferente.

Mapeamento de funções: grupo IdP para função SaaS#

O padrão standard: o IdP tem dois grupos - marketing-team (todos os colaboradores) e marketing-leads (líderes de equipa). A aplicação SaaS tem dois papéis: Marketer e Admin. A equipa de TI configura o mapeamento uma vez: marketing-team → Marketer, marketing-leads → Admin. Quando alguém muda de grupo, a próxima sincronização SCIM atualiza automaticamente a sua função.

O SCIM transporta a associação a grupos através do recurso Groups (GET /Groups, POST /Groups, PATCH /Groups/:id). Nem todas as implementações SCIM suportam sincronização de grupos - alguns fornecedores implementam apenas o provisionamento de utilizadores, o que significa que o mapeamento de funções ainda requer configuração manual por utilizador. Pergunte especificamente ao fornecedor se o envio de grupos SCIM é suportado e se o mapeamento de funções é configurável pelo administrador sem um ticket de suporte.

Para organizações baseadas na UE, os dados de associação ao grupo IdP que fluem através do SCIM podem em si mesmos constituir dados pessoais ao abrigo do Artigo 4(1) do RGPD. O artigo sobre residência de dados na UE para marketing cobre o que o seu DPA deve dizer sobre a camada de dados de identidade. O seu fornecedor SaaS é um processador desses dados, e o DPA deve abordá-lo explicitamente.

O que perguntar no procurement#

Cinco perguntas que determinam se a integração SSO/SCIM de uma ferramenta de marketing é meio dia de configuração de TI ou um projeto de várias semanas:

URL de metadados SAML. O fornecedor consegue fornecer um URL estático apontando para os metadados do SP (ID da entidade, URL do ACS, certificado de assinatura)? É o que cola no Okta ou no Entra. A entrada manual de metadados por cliente é um sinal de alarme.

Endpoint SCIM e método de autenticação. Qual é o URL base do SCIM? Bearer token é o padrão; as credenciais de cliente OAuth 2.0 são mais complexas. Qual é a cadência de rotação do token? Um token estático que nunca roda é um risco.

Latência de desprovisionamento. Quando o IdP envia PATCH /Users/:id { "active": false } ou DELETE, com que rapidez o acesso é encerrado? O intervalo de provisionamento do Entra está predefinido para 40 minutos no lado do IdP. O fornecedor deve comprometer-se com uma janela de processamento quando o pedido chegar. A combinação de ambas as latências é o que o seu auditor SOC 2 irá perguntar.

Suporte a envio de grupos. O envio de grupos SCIM é separado do provisionamento de utilizadores SCIM. Se o fornecedor implementar apenas sincronização de utilizadores, o mapeamento de funções requer configuração manual por utilizador. Pergunte especificamente.

Suporte a tile de IdP. A aplicação pode ser adicionada como tile no painel Okta ou Entra e suportar login iniciado pelo IdP?

A sobreposição de conformidade#

O controlo A.9.2 do Anexo A da ISO 27001 exige que os direitos de acesso dos utilizadores sejam concedidos, revistos e encerrados de acordo com um processo documentado. O A.9.3 exige que os utilizadores se autentiquem apenas com credenciais a eles atribuídas. O SCIM é o mecanismo operacional que liga o "offboarding de RH" ao "acesso SaaS revogado" sem passos manuais.

O SOC 2 CC6.2 exige que as entidades registem e autorizem utilizadores antes de conceder acesso. O CC6.3 exige revisão periódica e remoção de acessos. O registo de desprovisionamento SCIM - um registo com timestamp de quando o IdP instruiu a aplicação SaaS a desativar ou eliminar um utilizador - é o artefacto de auditoria que demonstra conformidade CC6.3 para cada aplicação no âmbito.

O Elido possui certificação ISO 27001. O SOC 2 Tipo II está em curso, com previsão para o 2.º semestre de 2026. A postura de identidade - SAML/OIDC via WorkOS, desprovisionamento SCIM 2.0, mapeamento de funções baseado em grupos - está documentada na página de confiança e no resumo de soluções/enterprise. Os BAAs estão disponíveis no plano Business para fluxos de trabalho adjacentes ao HIPAA.

O cornerstone do RGPD para encurtadores de URL cobre os Artigos 28 e 32 na íntegra. O SSO e o SCIM são os controlos técnicos do Artigo 32 - autenticação via SSO, desprovisionamento via SCIM - não funcionalidades autónomas. São componentes da postura de segurança que o seu DPO avalia durante a revisão do Artigo 32.

A /pricing mostra a comparação de planos e onde o SSO/SCIM aparece. A /solutions/compliance é o resumo voltado para a equipa de compras. A conversa sobre evidências de desprovisionamento pertence à mesma chamada de procurement que o DPA, a lista de sub-processadores e o compromisso de residência de dados - essas são as perguntas que determinam se uma ferramenta de marketing passa pela revisão de segurança.

As NIST SP 800-63-3 Digital Identity Guidelines, consultadas em 2026-05-12, são o framework autoritativo para níveis de garantia e tipos de autenticadores que sustentam muitos requisitos de política de IdP empresarial. A secção de federação - 800-63C - é diretamente relevante para a configuração de integração SAML e OIDC.