There are three ideas here, not two, and separating them clears up an enormous amount of confusion.
Identification is knowing who someone claims to be. Authentication is verifying that claim. Authorization is deciding what the verified party is permitted to do.
The humble API key sits right on the seam between the first two, which is exactly why it is so misunderstood. A key identifies the caller and lets you track them. It does not really verify them in any strong sense, and it says nothing at all about permissions unless you attach a scope or a plan to it server-side.
OAuth is where the third idea gets its own machinery. OAuth is a delegated authorization framework: the point is that a user can grant an application limited access to their account without handing over their password. People routinely describe OAuth as “login,” which is how you end up with badly scoped tokens and confused consent screens. OpenID Connect is the layer that adds identity on top of OAuth, and it exists precisely because OAuth alone was never an authentication protocol.
In your own design, keep the three separate on purpose: how a caller is identified, how that identity is proven, and what that identity is allowed to reach. Muddle them and you will find out which one you got wrong during an incident.
