OAuth 2.0 solves the delegated access problem where in a user authorizes a client (restricted access to his data)/(do some limited actions) on the resource server on his behalf , without sharing his credentials with client app . For example you can authorize an app to send tweets on your behalf.  OAuth was tweaked to allow the user to authorize access to his identity on resource server.

The confusion

OAuth is a delegated authorization framework yet it is extensively used in authentication use cases . Why?

Clarification

OAuth authorization flow has authentication events as during the OAuth flow, before the user can authorize the client to access an api , typically the user will have to authenticate , how ever, existence of these authentication events in the OAuth flow does not mean reliable communication of authentication to client as at the end of OAuth flow, the client gets an access token which it cannot read . In fact the audience of the access token is the resource server (which will read it for permissions/scope) . The client itself cannot determine user identity related information like name / email or if and when the user authenticated. Client can only use the token to access restricted data (based on user consent) or do some action on the resource server. So OAuth access tokens are about permissions/scopes and not user info(name/email)  or authentication info (like authentication time).

So while the OAuth framework solves the delegated authorization problem ,companies like google/face book started to use tweaked OAuth flows for the use case where a user can login to a site via google /facebook. In some sense, user is authorizing access to his identity related data in the resource server (google/face book) . So the authorization to identity access was done via OAuth flows (with tweaks) as access token is primarily about permissions. Also an advantage of tweaking the OAuth flow to accommodate identity use case is that with one call, an application can find out what is the data the app can access / actions the app can take and who has authorized the access.

OpenID Connect 1.0 is a layer on top of OAuth 2.0 framework to address these custom tweaks . It is specifically built to address the authentication use case. The major difference is that in addition to access token , the client gets an identity token which the client can use for information pertaining to identity.  Note that the audience for the id token is the client who can read the signed id token after verification. The identity is sent as a signed token to client directly which the client can verify and does not need to get identity via resource server identity api hit with access token.