OpenID Connect: How 'Sign in with Google' Works

The last chapter ended on a cliffhanger: OAuth grants access to your data but doesn't reliably prove who you are — yet "Sign in with Google" clearly logs you in. The resolution is OpenID Connect (OIDC), a thin identity layer built on top of OAuth. It's what actually powers social login across the web, and understanding it ties this guide together.

The gap: OAuth has no identity

Recall the precise limitation: an OAuth access token says "the bearer may read these photos." It does not say "this user is Alice." That's fine for delegated access, but useless — even dangerous — for login, where the entire point is to reliably establish who the user is.

The idea: add a standard identity layer

OpenID Connect keeps everything OAuth does and adds one thing: a standard, verifiable way to communicate who the user is. It reuses OAuth's whole flow — you're sent to the provider, you log in and consent — but the provider now also returns proof of identity.

Because OIDC sits on top of OAuth, you get both: the app can be granted access to data (OAuth) and reliably learn who the user is (OIDC), in one standardized flow.

The ID token

OIDC's central addition is the ID token — and you already understand its mechanics, because it's a JWT. It's a signed token, issued by the identity provider (Google, say), containing verified information about the user: a unique user ID, often their name and email, and when they authenticated.

The two token types now in play are easy to confuse, so keep them straight:

Because the ID token is a signed JWT from a trusted provider, your app can verify its signature and trust its claims about the user's identity — no guessing, no improvising. That verified "this is who the user is" is exactly what login needs and what OAuth alone couldn't give.

This is social login

Put it together and you've described every "Sign in with Google / GitHub / Apple" button you've ever clicked:

The appeal is mutual. Users skip yet another signup and password. You avoid storing credentials at all — you outsource the riskiest part of auth to a provider whose entire business is doing it well. That's why social login is everywhere.

Use the standard; don't roll your own

The practical takeaway closes the loop on the previous chapter's warning. If you want "log in with X," reach for OpenID Connect, not raw OAuth, and use a well-tested library or provider. OIDC exists precisely because doing identity-over-OAuth by hand is subtle and easy to get insecurely wrong. It standardizes the safe path — the ID token, the verification, the flow — so you don't have to invent the most security-sensitive layer of your system.

This echoes the guide's running theme from the basics chapter: authentication is high-stakes, and the right move is to lean on proven standards rather than improvise.

Recap

• OpenID Connect is an identity layer on top of OAuth — it adds "who is the user?" to OAuth's "what may the app do?"
• Raw OAuth can't safely power login because access tokens don't reliably prove identity; OIDC fixes that.
• OIDC adds the ID token — a signed JWT from the provider carrying verified identity claims.
• This is exactly what social login ("Sign in with Google") is under the hood.
• For login, use OIDC, not bare OAuth — outsource identity to trusted providers and don't roll your own.

OAuth and OIDC handle users and third-party apps. But what about machine-to-machine access — one server calling another's API with no human involved? That's where API keys come in. Continue to API Keys.