Pode criar uma conta no Elido em cerca de quatro segundos sem inventar mais uma password. Clique em "Continuar com GitHub", aprove a autorização e está dentro. O Elido suporta oito fornecedores de login social, e nenhum deles nos entrega a sua password, porque não há nenhuma a entregar.
O login social para um encurtador de URL significa utilizar uma identidade existente, a sua conta Google, GitHub ou Slack, para iniciar sessão em vez de registar um novo par email-e-password. O fornecedor atesta quem é; o Elido cria ou abre o seu workspace com base nisso. É o mesmo fluxo de um clique que já usou em dezenas de aplicações, aplicado à gestão de links. Esta publicação aborda os oito fornecedores que suportamos, como funciona o handshake, onde termina o login social e começa o SSO empresarial, e a questão que as equipas europeias fazem sempre: iniciar sessão com um fornecedor norte-americano arrasta os seus dados para o outro lado do Atlântico?
Os oito fornecedores, agrupados por quem os utiliza#
O Elido suporta Google, Microsoft, GitHub, GitLab, Slack, Discord, Facebook e X. Esta lista não é aleatória. Cada um corresponde a uma forma como as pessoas já organizam o seu trabalho.
Os programadores recorrem primeiro ao GitHub ou GitLab. Se está a encurtar links dentro de um pipeline de CI ou de um fluxo de release notes, iniciar sessão com a mesma conta que aloja os seus repositórios mantém o modelo mental consistente. As equipas de marketing e operações tendem a viver no Google Workspace ou no Microsoft 365, por isso "Continuar com Google" ou "Continuar com Microsoft" leva-as ao Elido usando a identidade com que toda a empresa já trabalha.
Depois há o lado da comunidade e dos criadores de conteúdo. Os logins com Slack e Discord encaixam em equipas que coordenam nessas ferramentas ao longo do dia. Um gestor de comunidade que gere um servidor no Discord e quer links curtos com marca para eventos pode registar-se com a mesma identidade do Discord. O Facebook e o X completam o conjunto para criadores e profissionais de marketing nas redes sociais cuja presença principal está nessas plataformas.
Escolhe um para se registar. Mais tarde pode associar os outros à mesma conta a partir das definições de segurança, para que o profissional de marketing que entrou com Google e o colega programador que entrou com GitHub acabem ambos no mesmo workspace.
Como funciona sem guardar a sua password#
Por baixo, os oito utilizam OAuth 2.0 e OpenID Connect, a mesma família de protocolos que alimenta o "Sign in with Google" em todo o lado. A camada de identidade do Elido é construída com Ory Kratos e Hydra, pelo que o fluxo segue normas estabelecidas em vez de algo que construímos de raiz.
Eis a sequência real. Clica no botão de um fornecedor. O Elido redireciona-o para a página de login do próprio fornecedor, no domínio do fornecedor, onde se autentica. Se tiver uma passkey ou chave de hardware configurada lá, usa-a lá. O fornecedor envia ao Elido um token de curta duração e um perfil mínimo: o seu email, o seu nome e um ID de utilizador estável. Trocamos esse token, criamos ou associamos a sua conta, e iniciamos a sua sessão. Em nenhum momento a sua password do fornecedor toca nos servidores do Elido. Não podemos expor o que nunca recebemos.
Esse último ponto é a história de segurança numa frase. Um registo clássico com email e password significa que cada aplicação a que adere se torna mais um lugar onde a sua password pode ser comprometida. O login social colapsa isso. Autentica-se uma vez, junto de um fornecedor com uma equipa de segurança maior do que a maioria das empresas, e herda de forma gratuita a autenticação multifator e a deteção de anomalias.
A contrapartida honesta é a concentração. Uma identidade abre agora mais portas, por isso proteja-a. Active o MFA no seu fornecedor e a balança pende claramente a favor do login social.
Quer ligar a criação de links diretamente aos seus próprios sistemas em vez de clicar em botões? Depois de entrar, a API e os SDKs permitem criar links curtos a partir de código em cinco linguagens. O login social deixa o utilizador entrar; a API trata das máquinas.
O login social não é SSO, e a diferença é importante#
As pessoas confundem isto constantemente, por isso vamos separá-los claramente.
O login social é para indivíduos. Você, pessoalmente, a optar por iniciar sessão com a sua conta Google. O SSO empresarial via SAML ou OIDC é para uma organização que quer controlo centralizado: provisionar e desprovisionar colaboradores através do Okta ou do Entra ID, garantir que todos autenticam através do fornecedor de identidade da empresa, e revogar acessos no momento em que alguém sai. O provisionamento SCIM situa-se ao lado, sincronizando o seu diretório para que as contas apareçam e desapareçam automaticamente.
Uma equipa em crescimento geralmente quer ambos, em fases diferentes. No início, três fundadores iniciam sessão com Google e avançam. Mais tarde, o departamento de TI diz que todas as ferramentas têm de passar pelo Entra ID, e activa o SSO para o workspace mantendo o login social disponível para os prestadores de serviços externos que não estão no diretório corporativo. Aprofundámos o lado dos processos de aquisição, as questões que o departamento de TI empresarial efetivamente coloca, em SCIM e SSO para ferramentas de marketing.
A versão resumida: não pague um contrato de SSO quando o que precisa é de um registo com um clique, e não tente esticar o login social como substituto do controlo de acessos gerido por diretório. São ferramentas diferentes para dimensões de problema diferentes.
A questão da residência de dados na UE#
Esta é a que surge em todas as chamadas de vendas europeias, por isso aqui está a resposta direta.
O handshake OAuth comunica com o fornecedor. Quando inicia sessão com Google ou Microsoft, essa etapa de autenticação atinge a infraestrutura deles, que pode estar fora da UE. Isso é verdade para o login social em qualquer produto, não apenas no nosso. O que não acontece é os seus dados do Elido serem transferidos. Os seus links, os seus eventos de clique, as suas análises, o workspace da sua equipa, tudo fica fixado na região da UE que selecionou ao criar a conta.
A autenticação e a residência de dados são camadas separadas. Iniciar sessão através de um fornecedor de identidade norte-americano é uma troca momentânea de token; não é onde os seus dados de negócio vivem. Se a sua postura de conformidade proibir que mesmo a etapa de autenticação toque num fornecedor norte-americano, utilize o GitLab ou uma opção de identidade alojada na Europa, ou imponha SSO através de um IdP com residência na UE. Para ter uma visão completa do que fica na UE e do que o seu DPO vai querer documentado, o RGPD para encurtadores de URL percorre tudo isso, e os detalhes da residência estão em Residência de dados na UE para análises de marketing.
Como ativar#
Não há quase nada para configurar como utilizador. No ecrã de registo, os botões dos fornecedores já estão lá. Escolha um, aprove a autorização, pronto.
Algumas coisas que vale a pena fazer depois de entrar:
- Associe um segundo fornecedor, ou adicione uma password, nas definições de segurança. Ter dois caminhos de acesso significa que uma interrupção de um único fornecedor nunca o bloqueia.
- Active o MFA no fornecedor que utiliza. É aí que reside a proteção real.
- Se for proprietário de um workspace, trate o seu método de início de sessão como uma credencial de produção. Não o deixe ligado a uma conta pessoal à qual possa perder o acesso.
Esse último ponto apanha muita gente. O freelancer que se regista com um Gmail pessoal, constrói os links de campanha de um cliente, depois muda de emprego e perde o Gmail, terá uma tarde difícil à sua frente. Associe um método de recuperação cedo.
O login social remove a password sem remover a sua responsabilidade pela conta que está por detrás. Configure um segundo método, active o MFA, e o registo de quatro segundos continua a ser um registo de quatro segundos, sem os dramas de bloqueio mais tarde.