What OpenID Connect adds to OAuth 2.0 (why is OAuth 2.0 not sufficient for authentication?)

Question

I've read a number of different write-ups on this now, but I'm still unclear as to the primary value that OpenID Connect provides on top of OAuth 2.0.

My understanding:
When receiving an access token via the OAuth 2.0 flow, the client does come to know that the user was authenticated by the authorization server. It seems like OpenID Connect is just adding an ID token with user information - but that information could be part of the access token or available through a protected resource (like a separate userDetails resource). That doesn't seem to justify the creation of OpenID Connect, so I'm sure that I'm missing something...

Thanks for your help!

Adding more details that are too long for a comment. Thanks much for your help so far.

I think I'm getting closer, thanks to your responses. So I reviewed this article: http://oauth.net/articles/authentication/. It says that "OAuth says absolutely nothing about the user". However, you are trusting that same service to authenticate the End-User before issuing an Access Token. In the "common pitfalls section", the article discusses why you can't use access token for authentication. I have the following issues with that in my understanding:

Access token as proof of authentication The access token was proof of authentication at some prior point. If the Client does want to authenticate the user at some point after getting an access token, why not just repeat the existing Oauth flow with the current end-user trying to access the client?

Access of a protected resource as proof Same as above - if the client requires authentication at any point, repeat the Oauth flow.

Injection of access tokens Not clear how OpenID helps this

Lack of audience restriction Why is it harder to hand a naive client a valid ID token along with the access token? Is this relevant at all to the server-side flow? And again, can repeat the OAuth flow if needed.

Injection of invalid user information This seems to require a signature, not a separate token. If the OAuth flow takes place over HTTPS, is it adding any security for the identity provider to sign user details twice?

Different protocols for every potential identity provider This seems fair, but it still seems strange if the only purpose would be standardization of the token used for user information.

Answer 1

An OAuth access token is opaque to the Client and could have been provided by anyone, which means that it is not necessarily handed to the Client by a logged in user. An attacker could provide an access token to the Client that it got from a different user in its own (not necessarily malicious) service. The ID token from OpenID Connect make sure that the user was logged in recently at the OP and provides information about that user that can be verified by the Client. Moreover the ID token is targeted specifically to your Client.

The differences are described pretty well in http://oauth.net/articles/authentication/