How Does "Sign in with Google" Work? OAuth Made Simple

IT Knowledge
4 min read

When signing up for a new service, you meet buttons like “Continue with Google” or “Sign in with Apple.” Press one and you’re logged in right away, without creating a new password. But does this service come to know your Google password? Fortunately, no.

In this post, I’ll unpack, without any code, how social login works and the OAuth approach beneath it.

Social login doesn’t hand over your password #

Starting with the core of social login: the service you’re signing up for never sees your Google password. The password is entered only into Google and is not passed to the service.

Instead, Google vouches to that service that “this person is indeed the one we verified.” Rather than receiving and checking the password itself, the service handles the login by taking Google’s trustworthy vouching. That’s why you don’t have to hand your password to every new service you sign up for.

It fetches a pass on your behalf #

The agreement for exchanging this vouching is OAuth. A hotel makes a close analogy. When you show your ID at the front desk, the desk doesn’t hand your ID itself to the room cleaner. Instead, it issues a card key that opens the room. The cleaner can only enter the designated room with that card key and doesn’t hold your ID information.

Social login is the same. Identity verification happens at the front desk called Google, and as a result the service receives a token, which corresponds to a kind of card key. Earlier, in keeping you logged in, I said a token serves as a pass; social login fetches that pass from Google on your behalf.

The consent screen is the core #

Press a social login button and you’re taken to Google’s screen. The place you enter your password is right here, that is, Google’s screen — not the screen of the service you’re signing up for. This distinction is at the heart of why social login is safe.

At this point, a screen also appears asking something like, “Do you consent to providing your name and email to this service?” It’s the step where you check and permit what will be handed over. The service can only take the information within the scope you consented to. That’s how the difference arises where some services request only name and email, while others request more permissions.

What it gets and what it doesn’t #

What the service receives is the token and only the information within the scope you consented to — usually about your name and email. Having a token doesn’t mean it can look into your whole Google account. It can’t do anything beyond the scope you consented to.

What’s more, this permission can be taken back later. Go into your Google account settings and there’s a list of services you’ve connected, where you can disconnect any you want. Disconnect one and that service’s token no longer works. So even after handing over the key, you can invalidate that key anytime.

So, when you use social login #

Social login is convenient, but there are points to weigh too. Sign-up and login are fast, and since the service doesn’t have to store a password, the risk of a leak drops. On the other hand, if something happens to that Google account, you may be locked out of all the services tied to it at once.

If you’re the one building, it’s good to get consent only for the information you truly need. Requesting excessive permissions makes users hesitate at the sign-up step. And all of this has to happen on top of HTTPS, which seals the communication, to be safe.

Why this makes work easier for non-developers #

  • You know why it’s safe. Knowing that the password is entered only into Google and not the service, you can explain to users why social login is comparatively safe.
  • You design the permission scope. Knowing that the more information the consent screen requests, the more users hesitate, you can decide to request only the scope you truly need.
  • You see the dependency risk. Knowing it’s a structure tied to an external account, you can think through in advance whether to keep your own login alongside it.

Wrapping up #

Today we looked at how social login works by not handing your password to the service, instead taking Google’s vouching as a pass called a token. The keys are that the password is entered only into Google, the service receives only the information within the scope you consented to, and that connection can be cut later.

If you’re curious how a token serves as a pass, read Why You Stay Logged In; if you’re curious about the HTTPS and encryption that underpin this process, read What the Padlock in Your Address Bar Protects.

X