You can create an Elido account in about four seconds without inventing another password. Click "Continue with GitHub," approve the prompt, and you're in. Elido supports eight social login providers, and none of them hand us your password, because there isn't one to hand over.
Social login for a URL shortener means using an existing identity, your Google or GitHub or Slack account, to sign in instead of registering a new email-and-password pair. The provider vouches for who you are; Elido creates or opens your workspace based on that. It's the same one-click flow you've used on dozens of apps, applied to link management. This post covers the eight providers we support, how the handshake actually works, where social login ends and company SSO begins, and the question EU teams always ask: does signing in with a US provider drag your data across the Atlantic?
The eight providers, grouped by who uses them#
Elido supports Google, Microsoft, GitHub, GitLab, Slack, Discord, Facebook, and X. That list isn't random. Each one maps to a way people already organize their work.
Developers reach for GitHub or GitLab first. If you're shortening links inside a CI pipeline or a release-notes workflow, signing in with the same account that holds your repos keeps the mental model tight. Marketing and ops teams tend to live in Google Workspace or Microsoft 365, so "Continue with Google" or "Continue with Microsoft" lands them in Elido using the identity their whole company already runs on.
Then there's the community and creator side. Slack and Discord logins fit teams that coordinate in those tools all day. A community manager who runs a Discord server and wants branded short links for events can sign up with the same Discord identity. Facebook and X round out the set for creators and social marketers whose primary presence is on those networks.
You pick one to sign up. Later you can attach the others to the same account from your security settings, so the marketer who joined with Google and the developer teammate who joined with GitHub both land in the same workspace.
How it works without storing your password#
Under the hood, all eight run on OAuth 2.0 and OpenID Connect, the same protocol family that powers "Sign in with Google" everywhere else. Elido's identity layer is built on Ory Kratos and Hydra, so the flow is standards-based rather than something we hand-rolled.
Here's the actual sequence. You click a provider button. Elido redirects you to that provider's own login page, on the provider's domain, where you authenticate. If you have a passkey or hardware key set up there, you use it there. The provider then sends Elido a short-lived token plus a minimal profile: your email, your name, a stable user ID. We exchange that token, create or match your account, and start your session. At no point does your provider password touch Elido's servers. We can't leak what we never receive.
That last point is the security story in one sentence. A classic email-and-password signup means every app you join becomes another place your password could be breached. Social login collapses that. You authenticate once, against a provider that has a security team larger than most companies, and you inherit their multi-factor and anomaly detection for free.
The honest tradeoff is concentration. One identity now unlocks more doors, so protect it. Turn on MFA at your provider, and the math swings firmly in social login's favor.
Want to wire link creation straight into your own systems instead of clicking buttons? Once you're in, the API and SDKs let you mint short links from code in five languages. Social login gets the human in; the API handles the machines.
Social login is not SSO, and the difference matters#
People conflate these constantly, so let's separate them cleanly.
Social login is for individuals. You, personally, choosing to sign in with your Google account. Enterprise SSO through SAML or OIDC is for an organization that wants central control: provision and deprovision staff through Okta or Entra ID, enforce that everyone authenticates through the company's identity provider, and revoke access the moment someone leaves. SCIM provisioning sits next to it, syncing your directory so accounts appear and disappear automatically.
A growing team usually wants both, at different stages. Early on, three founders sign in with Google and ship. Later, IT says every tool has to route through Entra ID, and you flip on SSO for the workspace while keeping social login available for contractors who aren't in the corporate directory. We dug into the procurement side of that, the questions enterprise IT actually asks, in SCIM and SSO for marketing tools.
The short version: don't pay for an SSO contract when what you need is a one-click signup, and don't try to stretch social login into a substitute for directory-managed access control. They're different tools for different sizes of problem.
The EU data residency question#
This is the one that comes up on every European sales call, so here's the direct answer.
The OAuth handshake talks to the provider. When you sign in with Google or Microsoft, that authentication step hits their infrastructure, which can sit outside the EU. That's true of social login on any product, not just ours. What it does not do is move your Elido data. Your links, your click events, your analytics, your team's workspace, all of it stays pinned to the EU region you selected when you created the account.
Authentication and data residency are separate layers. Signing in through a US identity provider is a momentary token exchange; it isn't where your business data lives. If your compliance posture forbids even the auth step touching a US provider, use GitLab or a European-hosted identity option, or enforce SSO through an EU-resident IdP. For the full picture of what stays in the EU and what your DPO will want documented, GDPR for URL shorteners walks through it, and the residency mechanics live in EU data residency for marketing analytics.
Turning it on#
There's almost nothing to configure as a user. On the sign-up screen, the provider buttons are already there. Pick one, approve the consent prompt, done.
A few things worth doing once you're in:
- Link a second provider, or add a password, from security settings. Two ways in means a single provider outage never locks you out.
- Turn on MFA at whichever provider you use. That's where the real protection lives.
- If you own a workspace, treat its sign-in method like a production credential. Don't leave it tied to a personal account you might lose access to.
That last point catches people. The freelancer who signs up with a personal Gmail, builds a client's campaign links, then changes jobs and loses the Gmail, has a bad afternoon ahead. Link a backup method early.
Social login removes the password without removing your responsibility for the account behind it. Set up a second method, switch on MFA, and the four-second signup stays a four-second signup, with none of the lock-out drama later.