What OAuth2 (RFC6749 at https://tools.ietf.org/html/rfc6749) tries to solve is delegated access control to a protected resource. Typically a user (the resource owner) gives consent so that a client can access a protected resource (a REST API endpoint for example).
However, it is/was common to abuse the protocol and introduce special ‘scopes’ like ‘signin’ or ‘authn’ or whatever so the client could access an endpoint (with that scope) to fetch the user information and potentially access other resources if other scopes were included.
As many people have pointed out, this is very bad practice because the client can never verify the access token was actually issued to him (think ‘audience’, as in the WS-Federation and SAML protocol). Needless to say, you can simply use a token obtained by a malicious app and use it in a legitimate client (app) and as such, impersonate another user.
Several victims (including Facebook) decided to take extra measures. In the end, one started to realize that all the bespoke measures caused too many incompatibilities and the Open ID Connect initiative was born.
Read more about it in the Open ID spec at http://openid.net/connect/
Read the story about why you shouldn’t use OAuth2 for authentication at http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html and http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/