The shortcut with a hole in it
Plenty of teams shipped a Login with X button by fetching a profile with an access token and trusting whatever came back.
See the hole in that shortcut. Access tokens are not addressed to anybody.
A malicious app that legitimately obtained a token from the same provider can replay it against your login endpoint. If you accept valid token for this person as this is that person, the attacker has just logged in as their own victim. Researchers demonstrated exactly this against production sign-on systems in 2012.
What the ID token adds
Close it with an ID token, which is what OpenID Connect adds. It is a signed token whose claims answer the authentication question directly.
One claim names the provider, one is a stable identifier for the user, one is your own client identifier, one bounds its life, and profile details ride along.
Verify the signature against the provider's published keys and then, decisively, check that your own identifier is the audience. A token minted for any other app fails that check no matter how valid its signature is. A one-time value in your login request binds the token to that request and closes replay.
Treat the mechanics as a small extension of what you already have. Add one scope to a normal authorization code flow and the token response includes an ID token alongside the access token.
Lean on discovery, which makes it plug-and-play. Every provider publishes a well-known address listing its endpoints and where its keys live, which is why one library handles Google, Microsoft and a self-hosted server identically.
Keep the division of labour straight, because interviews lean on it. OAuth answers what the holder may do, so send the access token to your APIs. OpenID Connect answers who logged in, so verify the ID token in your app and never forward it anywhere.
Worked example
A B2B startup ships its first Sign in with Google in two days: the SPA obtains an access token, calls Google's userinfo endpoint, and POSTs the returned email to /login, which starts a session for whatever address comes back. At the next pentest, the tester registers his own innocuous Google app, gets one target employee to try it, takes the access token his app legitimately received, and replays it against the startup's /login. Twenty minutes from setup to full account takeover, no password touched. Jonas, the backend lead, rewrites the whole path: a backend-run authorization code flow with the openid and email scopes, ID token signature verified against Google's JWKS, aud required to equal their own client_id, iss required to be accounts.google.com, and users looked up by the stable sub claim instead of by email, which can change or be re-registered.