SCIM e SSO em ferramentas de marketing: o que a TI 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 senha independente, sem credenciais compartilhadas, 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 chegando a esta revisão agora porque as equipes de marketing gerem PII na camada de eventos de clique. Uma hiperligação curta que registra o IP do usuário, o user-agent e o referrer está processando 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á perdendo 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 usuário 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 usuário 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 usuário em aplicações SaaS. Três operações principais:

Provisionamento: POST /Users com os atributos do usuário. 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 registra-o, e esse registro é o artefato de auditoria.

A lacuna das ferramentas de marketing

A maioria das categorias de SaaS empresarial - RH, CRM, ITSM, hospedagem de código - inclui SSO em planos que uma equipe 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 usuários 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 equipe de marketing opera a ferramenta fora do IdP - o resultado que a TI está tentando 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á olhando 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 equipe de TI está documentada e testada; caso contrário, estão escrevendo 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, por isso o desprovisionamento não é instantâneo. Vale a pena mencionar na revisão de procurement.

JumpCloud suporta SAML 2.0 e OIDC, além de SCIM 2.0. Popular em equipes 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 e OIDC, com SCIM por cima. 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 usuário final) que as aplicações SaaS usam para implementar SSO e SCIM. Um fornecedor que diz "usamos WorkOS" está expressando 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 usuário na primeira vez que o usuário 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 usuário é 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 usuários 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 registro auditável de que o acesso foi encerrado?". O JIT não gera esse registro. O SCIM gera: o evento DELETE ou { "active": false } é registrado 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á respondendo a uma pergunta diferente.

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

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

A associação a grupos viaja através do recurso Groups do SCIM (GET /Groups, POST /Groups, PATCH /Groups/:id). Nem todo fornecedor oferece suporte. Alguns implementam apenas o provisionamento de usuários, o que significa que o mapeamento de funções ainda requer configuração manual por usuário, uma conta de cada vez, sempre que alguém muda de equipe. 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.

Organizações baseadas na UE têm mais uma coisa a verificar. 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, e o seu fornecedor SaaS é um processador desses dados. O seu DPA deve dizer isso. O artigo sobre residência de dados na UE para marketing cobre o que ele deve dizer sobre a camada de dados de identidade.

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 é um recurso separado do provisionamento de usuários SCIM. Se o fornecedor implementar apenas sincronização de usuários, o mapeamento de funções exige configuração manual por usuário. 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 usuários sejam concedidos, revistos e encerrados de acordo com um processo documentado. O A.9.3 exige que os usuários se autentiquem apenas com credenciais a eles atribuídas. Na prática, 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 usuários antes de conceder acesso. O CC6.3 exige revisão periódica e remoção de acessos. O registro de desprovisionamento SCIM - um registro com timestamp de quando o IdP instruiu a aplicação SaaS a desativar ou eliminar um usuário - é o artefato de auditoria que demonstra conformidade CC6.3 para cada aplicação no âmbito.

O Elido não tem certificação ISO 27001, e o SOC 2 está em preparação, sem relatório emitido ainda. A postura de identidade - SAML/OIDC via WorkOS, desprovisionamento SCIM 2.0 e uma função padrão por diretório (o mapeamento de grupo para função ainda não está disponível) - está documentada na página de confiança e no resumo de soluções/enterprise. Para fluxos de trabalho adjacentes ao HIPAA, um BAA é um acordo separado no Business e no Enterprise, solicitado a [email protected].

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 equipe 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 seção de federação - 800-63C - é diretamente relevante para a configuração de integração SAML e OIDC.