SSO & SCIM. Enterprise identity, zero friction.
Login SAML / OIDC em qualquer IdP importante. O diretório SCIM sincroniza o provisionamento e desprovisionamento de usuários automaticamente. Os segredos dos webhooks rotacionam sem perder o estado.
- SAML / OIDC against 20+ identity providers
- SCIM directory sync — provision and deprovision automatically
- Webhook secret rotation without downtime
- Full audit trail for compliance
SCIM directory sync
Provision and deprovision in under 60 seconds
Connect your IdP directory once. Every hire, transfer, and departure propagates to Elido automatically — no IT ticket, no manual invite, no forgotten offboarding gap.
- Auto-provisioningSCIM CREATE from Okta or Entra → Elido account in under 60s
- Group-to-role mappingIdP groups map to Elido roles; changes propagate on next sync
- Instant deprovisioningSCIM DELETE or active: false → sessions revoked immediately
- API key suspensionAll user API keys suspended on offboarding — no access-after-departure gap
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika SaloMember
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika Salodeprovisioned
Identity providers
Works with every major IdP
Elido uses WorkOS as the SSO and SCIM broker — 20+ connections out of the box, plus Generic SAML for any SP-initiated flow. Configure the Elido application in your IdP once; Elido generates the SAML metadata XML or OIDC credentials.
Any SAML 2.0-compliant IdP works via Generic SAML. See the setup guide →
- User provisioned via SCIMokta-scim-svc10.0.1.409:12:04
- SSO login — Oktaana@corp.com91.223.4.1709:14:31
- SSO login — Azure ADben@corp.com185.46.9.209:17:08
- Webhook secret rotatedadmin@corp.com77.123.11.510:05:22
- User deprovisioned via SCIMokta-scim-svc10.0.1.414:33:51
- Role changed: Member → Adminadmin@corp.com77.123.11.515:01:09
Audit trail
Immutable identity event log
Every SSO login, SCIM provision, role change, and secret rotation is logged append-only. No admin can delete entries. Export to CSV or stream to your SIEM via API.
- Timestamp, actor, action, target, and IdP connection per event
- 12-month retention on Business; longer available on request
- API export for SOC 2, ISO 27001, DORA, and NIS2 evidence
- Failed SSO attempts logged with reason code
- IP-based alerting for SSO probing threshold
- Secret rotations reference the overlap window in the log
What you can do
- Okta, Azure AD / Entra, Google Workspace
- Mapeamento de domínio de e-mail → conexão
- Criação / atualização / exclusão de usuário SCIM
- Verificação de assinatura de webhook (HMAC-SHA256)
O que o SSO empresarial e o provisionamento SCIM realmente exigem em produção
O redirecionamento SAML é o básico. Os detalhes abaixo cobrem latência de provisionamento, mapeamento de funções, rotação de segredos e os modos de falha que importam para as equipes de segurança.
Login SAML 2.0 e OIDC via WorkOS — roteamento de domínio de e-mail para a conexão IdP correta
O Elido utiliza o WorkOS como broker de SSO, que suporta mais de 20 conexões IdP, incluindo Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate e qualquer IdP compatível com SAML 2.0. Sua equipe de TI configura o aplicativo Elido no seu IdP uma única vez; o Elido gera um XML de metadados SAML ou credenciais de cliente OIDC para o assistente de configuração do IdP. O roteamento de domínio de e-mail mapeia os domínios de e-mail do usuário para a conexão IdP correta — usuários com @suaempresa.com são roteados automaticamente para a sua conexão Okta sem precisar selecioná-la. Vários domínios de e-mail podem ser mapeados para uma única conexão (para empresas com entidades fundidas ou vários domínios de e-mail). O provisionamento JIT cria a conta Elido no primeiro login SSO se o SCIM não estiver em uso; se o SCIM estiver ativo, o JIT é desativado e a conta deve ser provisionada via SCIM antes do primeiro login.
Sincronização de diretório SCIM 2.0: provisionamento automático, desprovisionamento e mapeamento de grupo para função
O SCIM 2.0 sincroniza o diretório de usuários do seu provedor de identidade com o Elido. Quando um usuário é adicionado ao grupo do aplicativo Elido no Okta ou Entra, o Elido recebe um evento CREATE do SCIM e provisiona a conta do usuário — sem chamado de TI, sem convite manual. As atualizações de perfil do usuário (nome, e-mail) se propagam automaticamente. Quando um usuário é removido do grupo ou desativado no IdP, o Elido recebe um evento DELETE ou PATCH (active: false) do SCIM e revoga imediatamente o acesso — as sessões ativas são invalidadas e as chaves de API pertencentes ao usuário são suspensas. O mapeamento de grupo para função permite mapear seus grupos de IdP (ex: 'Admins Elido', 'Visualizadores Elido') para funções do Elido (Admin, Membro, Visualizador). As atribuições de funções são atualizadas automaticamente quando a participação no grupo muda no IdP. A latência de provisionamento desde o evento no IdP até a criação da conta no Elido é tipicamente inferior a 60 segundos.
Segredos de assinatura de webhook rotacionam sem perder eventos em trânsito — procedimento de rotação com tempo de inatividade zero
O receptor de webhooks SCIM do Elido e o sistema de webhooks de saída usam assinaturas HMAC-SHA256 para verificar a autenticidade dos eventos. Os segredos expiram e precisam de rotação — seja em um cronograma (recomendado: 90 dias) ou após uma suspeita de comprometimento. A rotação com tempo de inatividade zero funciona da seguinte forma: gere um novo segredo no painel (o segredo antigo permanece válido por 15 minutos durante a janela de sobreposição), implante o novo segredo em seus sistemas, verifique se um evento SCIM de entrada é verificado com o novo segredo e, em seguida, acione a expiração imediata do segredo antigo. A janela de sobreposição de 15 minutos garante que os eventos em trânsito assinados com o segredo antigo ainda sejam processados durante a janela de implantação. A rotação de segredos é registrada na trilha de auditoria com data e hora, o autor (o admin que rotacionou) e a confirmação da expiração da sobreposição.
Log completo de eventos de identidade: logins SSO, eventos de provisionamento, mudanças de função e rotações de segredos
Cada login SSO, provisionamento/desprovisionamento SCIM, alteração de atribuição de função e rotação de segredo é registrado na trilha de auditoria do workspace (Business). Cada entrada inclui: data e hora, autor (usuário ou serviço SCIM), tipo de ação, alvo (o usuário ou recurso afetado), conexão IdP usada e o ID do workspace. A trilha de auditoria é apenas para adição (append-only) e imutável — nenhum admin pode excluir entradas. Exporte para CSV ou consulte via API para ingestão em SIEM. Se a sua estrutura de conformidade exigir evidências de eventos de controle de acesso (SOC 2 Type II, ISO 27001, DORA, NIS2), a trilha de auditoria é o artefato. A retenção é de 12 meses no plano Business; retenções maiores estão disponíveis mediante solicitação para setores regulamentados.
Expiração forçada de sessão via SCIM — acesso revogado em menos de 60 segundos na desativação do IdP
Quando o SCIM sinaliza que um usuário foi desativado (offboarding de funcionário, término de contrato de prestador de serviço), o Elido invalida imediatamente todas as sessões ativas desse usuário e suspende suas chaves de API. Isso não depende do TTL do cookie de sessão — o Elido armazena uma flag de revogação por ID de usuário e a verifica em cada requisição autenticada. O tempo desde a desativação no IdP até a revogação do acesso no Elido é a latência de entrega do evento SCIM: normalmente menos de 30 segundos para Okta e menos de 60 segundos para Azure Entra. Para offboarding de alta segurança (ex: um admin saindo), um administrador do workspace do Elido também pode revogar manualmente as sessões de um usuário específico no painel antes que o evento SCIM chegasse. As sessões revogadas manualmente e as revogações acionadas por SCIM aparecem na trilha de auditoria.
Equipes de segurança empresarial usando SSO & SCIM do Elido
Nomes são espaços reservados — estudos de caso reais de clientes serão publicados aqui conforme forem lançados.
“O offboarding via SCIM era o requisito que nossa equipe de segurança tinha desde o primeiro dia. Quando um funcionário é desativado no Entra, o acesso ao Elido desaparece em menos de um minuto — sem chamado manual de desprovisionamento, sem lacuna de 'esqueci de revogar'. Auditamos os logs após três meses e encontramos zero eventos de acesso após o desligamento.”
“Temos cinco domínios de e-mail da empresa de duas aquisições. O roteamento de domínio de e-mail → IdP no Elido lida com todos os cinco apontando para a mesma conexão Okta. Usuários de qualquer domínio encontram o fluxo de SSO correto sem precisar escolher em uma lista.”
“A rotação de segredos sem tempo de inatividade foi o detalhe que nos convenceu. Rotacionamos os segredos de webhook trimestralmente por política; a janela de sobreposição de 15 minutos significa que podemos rotacionar durante o horário comercial sem risco de incidentes. Cada rotação é registrada, auditada e referenciada em nosso pacote de evidências SOC 2.”
Elido SSO & SCIM vs Bitly vs Rebrandly
O SSO está disponível no plano Enterprise do Bitly e no plano Business do Rebrandly. O provisionamento SCIM é mais limitado em ambos. A comparação cobre o que cada um realmente entrega.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SAML 2.0 SSO | Sim — broker WorkOS, 20+ conexões IdP | Sim — plano Enterprise | Sim — plano Business |
| OIDC SSO | Sim — junto ao SAML via WorkOS | Apenas SAML | Apenas SAML |
| Provisionamento SCIM 2.0 | Criação / atualização / exclusão completa + mapeamento de grupo para função | Limitado — apenas criação de usuário, sem mapeamento de grupo para função | Não disponível |
| Auto-desprovisionamento no offboarding | Sim — SCIM DELETE, sessão revogada em menos de 60s | Apenas manual | Apenas manual |
| Roteamento de IdP por domínio de e-mail | Sim — vários domínios por conexão | Único domínio por conexão | Não documentado |
| Trilha de auditoria para eventos de identidade | Sim — imutável, 12 meses, exportação via API | Log de auditoria limitado | Log de auditoria limitado |
| Rotação de segredo de webhook (tempo de inatividade zero) | Sim — janela de sobreposição de 15 minutos | Não se aplica | Não se aplica |
Perguntas sobre SSO & SCIM
Quais provedores de identidade são suportados?
O Elido utiliza o WorkOS como broker de SSO e SCIM, que suporta Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud e qualquer IdP compatível com SAML 2.0. Conexões OIDC também são suportadas para provedores como Google Workspace e Azure. Se o seu IdP não estiver na lista padrão do WorkOS, o tipo de conexão 'SAML Genérico' do WorkOS funciona com qualquer fluxo iniciado pelo provedor de serviço (SP-initiated) SAML 2.0. Entre em contato conosco se precisar de uma conexão IdP específica não listada.
O que é provisionamento JIT vs provisionamento SCIM?
O provisionamento JIT (Just-in-Time) cria uma conta de usuário no Elido em seu primeiro login via SSO — nenhum pré-provisionamento é necessário. É mais simples de configurar, mas não oferece controle sobre quem pode fazer login (qualquer pessoa com uma asserção SSO válida ganha uma conta). O provisionamento SCIM dá o controle ao seu IdP: apenas usuários no grupo provisionado podem fazer login, e as contas são criadas antes do primeiro login. Para ambientes empresariais onde o acesso deve ser pré-aprovado, o SCIM é obrigatório. Quando o SCIM está ativo, o provisionamento JIT é desativado.
Como funcionam os mapeamentos de grupo para função do SCIM?
Nas configurações de SSO do workspace, você mapeia seus grupos de IdP para funções do Elido: ex: 'Grupo Okta: Admins Elido' → 'Função Elido: Admin', 'Grupo Okta: Membros Elido' → 'Função Elido: Membro'. A função de um usuário no Elido segue sua participação no grupo do IdP — se ele for movido do grupo de Admins para o grupo de Membros no Okta, sua função no Elido é rebaixada na próxima sincronização SCIM (normalmente em menos de 60 segundos). Um usuário em vários grupos assume a função de maior privilégio dos mapeamentos correspondentes.
O SSO pode ser obrigatório para todos os usuários ou é opcional?
O SSO pode ser definido como obrigatório (todos os usuários devem fazer login via SSO — o login por senha é desativado) ou opcional (os usuários podem escolher entre SSO ou e-mail+senha). No plano Business, a obrigatoriedade é configurada nas configurações de SSO do workspace. Uma vez obrigatório, os usuários que não possuem uma identidade SSO ativa ficam bloqueados — certifique-se de que o provisionamento SCIM ou JIT tenha gerado as contas antes de habilitar a obrigatoriedade. As contas de administrador podem ser isentas da obrigatoriedade do SSO como um mecanismo de segurança emergencial; isso é configurável.
O que acontece com as chaves de API quando um usuário é desligado via SCIM?
Quando o SCIM desativa um usuário, o Elido suspende todas as chaves de API que foram criadas por esse usuário. Chaves suspensas retornam HTTP 401 na autenticação. As chaves não são excluídas — elas permanecem visíveis para os administradores do workspace para fins de auditoria, com um rótulo de status 'suspensa — usuário desligado'. Se uma conta de serviço estava usando uma chave de API pessoal (não uma chave de serviço do workspace), a suspensão da chave quebrará essa integração — isso é intencional. Para integrações de produção, use chaves de serviço de nível de workspace em vez de chaves de API de usuário.
O SSO está disponível no plano Pro ou apenas no Business?
SSO e SCIM são recursos exclusivos do plano Business. Workspaces Pro usam a autenticação nativa do Elido (e-mail + senha via Ory Kratos, OAuth opcional do Google/GitHub). Se o SSO for um requisito indispensável para a aprovação de compras, o plano Business é o ponto de partida. Entre em contato com vendas para um teste do plano Business se precisar avaliar o SSO antes de se comprometer.
Como lidar com o SSO para um workspace que possui várias marcas ou sub-organizações?
Cada workspace do Elido possui sua própria configuração de SSO — se você gerencia vários workspaces (ex: por marca, por unidade de negócio), cada um recebe sua própria conexão IdP e provisionamento SCIM separadamente. Os usuários podem ser membros de vários workspaces com funções diferentes em cada um; sua identidade no IdP é a mesma, mas os mapeamentos de grupo para função são avaliados por workspace. Um grupo compartilhado do Okta pode ser mapeado como Admin em um workspace e Membro em outro.
Existe uma trilha de auditoria para tentativas de SSO com falha?
Sim. Tentativas de SSO malsucedidas (asserção SAML inválida, sessão expirada, conta SCIM ausente quando o JIT está desativado) são registradas na trilha de auditoria do workspace com o código do motivo. Isso é útil para diagnosticar por que um usuário específico não consegue fazer login e para detectar sondagens de SSO por força bruta. Tentativas falhas de endereços IP que excedem um limite acionam um alerta do workspace (configurável nas configurações de segurança do workspace).
Keep reading
SSO do portal white-label — seus clientes fazem login no seu painel personalizado via IdP deles.
Webhooks de saída assinados com HMAC — o mesmo padrão de rotação de segredo se aplica às assinaturas de webhooks de saída.
Chaves de serviço de workspace para integrações de API de produção — com escopo no workspace, não em usuários individuais.
SOC 2, ISO 27001, residência na UE e edge dedicado — a pilha completa de recursos empresariais.
Pronto para experimentar?
Comece no plano gratuito, faça o upgrade quando precisar de um domínio personalizado.