The name causes real, persistent confusion, so it's worth being precise from the start. OAuth 2.0 is a delegation protocol — it's how your application gets permission to act on a user's behalf against another service (Google, GitHub, a bank's API), without that service ever handing your application the user's actual password. That's authorization: "what is this app allowed to do."
Authentication — "who is this user, actually" — isn't something OAuth itself defines. It's a side effect that OpenID Connect (OIDC), a thin identity layer built directly on top of OAuth 2.0, formalizes with an additional, standardized ID token. In practice, "Login with Google" uses both together — OAuth to get permission to read the user's basic profile, OIDC to get a verifiable statement of who they are — which is exactly why the two terms get blurred in casual conversation. Precisely:
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Answers | "Is this app allowed to do X?" | "Who is this user?" |
| Core artifact | Access token | ID token (a JWT) |
| Token audience | The resource server (an API) | Your own application |
| Built for | Delegated access to an API | Federated login / identity |
A genuinely useful test: if all your application does with the result is call an API on the user's behalf (read their calendar, post a tweet), that's plain OAuth. If your application needs to know who logged in so it can create a local user session, that's OIDC layered on top.