Book a call ENES

Third-party login: a guide for businesses

6 min readErick Araya Gamboa, Intern

Person in a gray shirt using their phone in front of a laptop at a desk

Someone arrives at your platform eager to try it, finds a form asking for a name, an email, a password, a password confirmation and a code sent by email, and leaves. Sign-up is the moment when most users drop off, almost always for the same reason: it is one more chore and one more password to remember.

Third-party login solves that problem. Instead of creating a new account, people sign in with one they already have, such as Google, Microsoft or Apple, in one or two clicks. This guide explains what it is, what users gain, what your business gains, which providers to offer and what to watch for when you add it.

1. What third-party login is

It is the "Continue with Google" or "Sign in with Microsoft" button you see on many platforms. Behind it are two open standards, OAuth 2.0 and OpenID Connect, which work like this:

  1. The person clicks the button and their browser takes them to the provider's page, for example Google.
  2. They sign in there, with their password and, if they have it turned on, their two-step verification.
  3. The provider asks whether they allow certain data to be shared with your platform, such as their name and email.
  4. The provider sends your platform a verified identity, digitally signed, confirming who the person is.

The key point is that your platform never sees the password. It only receives the provider's confirmation that the person is who they say they are.

Hand holding a phone with the fingerprint sensor on the lock screen
People sign in on the provider's page, with the security that provider already gives them.

2. What users gain

  • One click instead of a form. No details to type and no confirmation emails to wait for.
  • No new password to make up, write down or forget.
  • A large provider's security. Google, Microsoft and Apple invest in two-step verification, suspicious sign-in detection and alerts far beyond what a small platform can.
  • Trust. People sign in on a page they know, and they don't hand their password to a site they are visiting for the first time.

3. What your business gains

  • More completed sign-ups. Every field and every step in a form is a point where someone can give up; with one click, people get to what they came for sooner.
  • Less support. "I forgot my password" requests and accounts locked by failed attempts go away.
  • Less risk. If your platform doesn't store passwords, there are no passwords to leak.
  • Fewer fake accounts. Creating accounts in bulk is harder when each one has to be backed by a real account with a provider.
  • Richer profiles, with permission. With the person's consent, the provider shares details such as their name, verified email or profile photo, so they don't have to type them.

4. Which providers to offer

The choice depends on who your users are and where they come from:

Provider Worth it when your users…
Google Are the general public, or use Gmail and Google Workspace at work.
Microsoft Are companies or institutions that work with Microsoft 365 and Outlook.
Apple Use an iPhone or a Mac. If you publish an App Store app that offers third-party login, Apple also requires an equivalent privacy-focused option, such as "Sign in with Apple".
GitHub Are developers or technical teams.
Steam, Discord or Xbox Belong to a gaming community.

The buttons also tell people who the platform is for. A business tool that offers Microsoft feels built for that environment, and a gaming community that offers Steam or Discord speaks directly to its audience. On platforms like these, with the person's permission, the provider can also share data from its own world, such as the games they own or their achievements.

Offering at least two providers, plus email as a fallback, avoids shutting out people who don't have, or don't want to use, a particular account.

5. What to decide before you start

Third-party login comes with trade-offs worth settling from the start:

  • Provider dependence. If the provider changes its terms or has an outage, access to your platform is affected. Offering more than one provider lowers that risk.
  • Account linking. Decide what happens when someone who already has an account with their email later signs in with Google using the same email: whether the two accounts are merged or kept separate.
  • Privacy. Ask only for the permissions your platform needs, explain in your privacy policy what data you receive from each provider and what you use it for, and follow the data protection laws that apply to you, such as Law 8968 in Costa Rica.

Common mistakes when adding it

The integration is simple to start and easy to get wrong. These are the mistakes most worth avoiding:

  • Trusting an identifier sent by the browser. The person's identity should be read from the document the provider signs after authenticating them. If your platform accepts an identifier sent by the browser, anyone could pose as someone else.
  • Leaving the return to your platform unprotected. The step where the provider sends the person back is the most sensitive one. The standards include mechanisms to protect it (the state and PKCE parameters), and tokens should never travel in the page address, where they end up in the history.
  • Mixing addresses in the same flow. To a browser, two addresses that look the same can be different sites; if sign-in starts on one and returns to another, the session is lost.
  • Not letting people choose the account. Many people have a personal account and a work one. Asking the provider to show the account picker keeps them from signing in with the wrong one.
  • Keeping secrets in the code. The keys the provider gives you belong in the server's configuration, never in the repository. If one leaks, replace it right away.
  • Linking one external account to two users. The database should prevent the same Google account from being linked to two different users.
  • Doing heavy work during sign-in. If signing in requires syncing information, such as a history or a library, do it in the background rather than while the person waits for the page to load.
Person coding on a laptop, with a second laptop open in the background
The security details are handled on the server, out of the person's sight.

How to tell if it works

Before you turn it on, write down where sign-up stands today: how many people who start the form finish it, how many "I forgot my password" requests you get each month and how many fake or duplicate accounts show up. A few weeks after offering third-party login, compare the same figures and check which provider most people choose: it will tell you whether the buttons you offer are the ones your audience uses.

Third-party login turns the most delicate moment, sign-up, into one trusted click, as long as it is built carefully. If you want to add it to your platform, or connect it with the systems your business already uses, take a look at our integrations service or our custom software service.

Back to the blog

Want to apply this in your organization?

Book a free 30-minute assessment and we will show you where to start.

Tell us about your case and we will show you where to start.

Thirty minutes are enough to understand your case and tell you where to start, with what scope and in what timeframe. No cost and no commitment.

Leave your details