What is the "pseudo-authentication" problem when OAuth is used for login, explained with the valet key analogy?

An OAuth access token is like a valet key: it opens the house (the account's API) but is not personalised, so anyone who presents it gets access; it does not prove to the app who the presenter is. OIDC instead issues a notarised letter (the ID token) that states who the user is and to whom it is addressed.

* A signed letter naming the user and the recipient, versus a key that opens the door for whoever holds it. *

Pseudo-authentication with OAuth: the app says "give me the valet key to your house, so I know you are the owner". The user asks the provider to issue a valet key for the core APIs and hands it over. The app concludes: whoever can give me a key must be the owner. But the key carries no name and no addressee: an attacker who obtained a key from another app could hand it over too, and the app would log them in as the victim.

Real authentication with OpenID Connect: the app says "who are you? send me a notarised referral letter". The provider writes a letter stating name: Real Name, email: user@gmail, notary: Google, addressed to this specific app (the aud claim) and signed. The app can check who wrote it, whom it is about and that it was meant for this app.

Go deeper:

• OAuth (Wikipedia): OpenID vis-à-vis pseudo-authentication using OAuth — the same comparison, with the original drawing it is based on.
• oauth.net: End User Authentication with OAuth 2.0 — the token-substitution pitfall in detail.