Why is plain OAuth 2.0 unsuitable as a login (authentication) protocol?
Because the authorization server deliberately gives the client no user ID or other user data, and OAuth has no way to influence the authentication (for example to force a fresh login) or to transmit information about how the user was authenticated in a secured way.
Two capabilities that a login needs are missing:
- Who is the user? An access token is meant for the resource server, not the client; the client is not supposed to read it, and its format is undefined. So the client learns nothing standardised about the user.
- How and when did they authenticate? There is no parameter to demand a re-login or a certain authentication strength, and no signed statement saying "this user authenticated at 10:42 with a password and a second factor".
Because the demand for "Log in with..." buttons was huge, providers such as Facebook and Amazon built proprietary extensions: the client used the OAuth access token to call a provider-specific "who am I" API and treated the result as the login. Each provider did this differently, and some implementations were exploitable (an access token issued to one app could be replayed at another app that accepted it as a login). OpenID Connect standardised the missing parts.
Go deeper:
oauth.net: End User Authentication with OAuth 2.0 — the common pitfalls of building login on plain OAuth, and how OIDC fixes them.- heise: OpenID Connect, Login mit OAuth, Teil 1 — why OAuth alone does not provide login (in German).