What they're testing
Whether you separate "who someone is" from "what they may do".
The short answer~30 seconds
OAuth 2.0 is an AUTHORISATION protocol: it gives your application an access token to call APIs on a user's behalf. It says nothing about who that user is — an access token is a ticket, not an identity document. OpenID Connect is a thin layer on top that adds a signed id_token (a JWT) carrying the user's identity. If you're building "sign in with Google", the thing you need is OIDC.
The long answer
The practical consequence of conflating them: if you authenticate by calling a "get my profile" API with an access token, you have no way to know which APPLICATION that token was issued to. Another app can obtain a legitimate token for its user and hand it to you, and you log them in as that person. This is the confused deputy problem, and the id_token solves it with the aud claim — stating who the token is for.
On flows, current guidance has converged: Authorization Code with PKCE for everything — web, mobile and SPAs alike. The implicit flow is deprecated because it returns the token in the URL fragment, where it lands in browser history and referrers. Noting that implicit is obsolete reads well, because a great deal of material online still teaches it.
What they'll ask next
?What problem does PKCE solve?
Authorization-code interception. The client generates a random secret, sends its hash when starting the flow, and the original when exchanging the code — so an attacker who intercepts the code can't redeem it. Designed for mobile originally, now recommended even for confidential clients.
These lose points
- Using an access token as proof of identity. That's the confused deputy hole, and it has shipped in very large products.