In OAuth, you have a server that both 1. knows who a user is (can authenticate them) and 2. can do things on behalf of the user (send emails, provide files). A 3rd party client says "I want to send an email via this user, please authorize it" without particularly caring _who_ the user is.
In OpenID Connect you have a server that 1. knows who a user is. But the _3rd party client_ is the one can do things on behalf of the user (post messages on a forum, add details to a map, etc). So the 3rd party, via OpenID, says "tell me who this user is" and then after getting the identity the 3rd party itself decides whether to allow the actions or not.
And you can use them together! Since OpenID is some additional requirements on top of OAuth, you can use it to say "I want to do X and Y on behalf of this user, and while you're at it tell me who they are so I can do authorization for stuff on my side as well."
But neither OpenID nor OAuth specify how to do authentication! Whether that's a username/password, a security token, biometrics, etc. or a combination is totally up to the implementation.
The OpenID spec itself makes three confusing claims in the first 3 sentences:
> OpenID Connect 1.0 is a simple identity layer
Yes!
> It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server
No! Google + co might be Authorization servers, but there's no reason the OpenID provider needs to (or even has the capability) to do any authorization.
> This specification defines the core OpenID Connect functionality: authentication
No! OpenID doesn't specify how to do authentication, and that's not OpenID Connect's core functionality! Providing identity is!
The top SO answer on the difference between OpenID and OAuth:
> OpenID is about authentication (ie. proving who you are), OAuth is about authorisation
And you'll find similar comments all over the internet, Stack Overflow, etc.