> Most people think about auth in terms of usernames/passwords or API keys.
OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication.
But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.
Yeah, this misconception is at the heart of so much confusion, and far too many OAuth implementations were clearly borne of "well, the customer was demanding we support OAuth so we implemented it", and there was clearly no understanding of the distinction between authn and authz, or what use cases are actually getting solved.
I once worked with a vendor who provided an API and required all API clients to use OAuth with Auth Code Grant Flow. The API was designed to support backend automation use cases within the product, and could execute functionality behind the scenes headlessly. Auth Code Grant Flow requires interactive login by a user sitting at a keyboard, and they never stopped to consider that backend automation use cases are not going to work well if someone has to periodically execute an interactive auth flow. This wasn't a once-in-a-year occurrence since they enforced relatively short refresh token timeouts.
The degree of confusion and the prevalence of that confusion on this subject is quite high. Someone gets a task to "Implement OAuth", and they see that Auth Code Grant Flow is the most common, so that must be what we should implement.
OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication.
But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.