A confession. I wrote a recent article for SecureIDNews. Somewhere between myself, corporate review, and the copy editor, the piece ended up with a headline I myself would not have chosen (or at least don't remember choosing and so am here retroactively shifting blame) - "OAuth 2.0: Enabling identity for the cloud, mobile". The article gave an overview of OAuth 2.0 - what it is and why it's a useful tool for securing APIs - now recognized as the most important architectural development for cloud and mobile since sliced threads.
Given the title, the casual reader might be forgiven for thinking that OAuth was somehow focused on identity. Sorry about that.
The truth is that OAuth 2.0 actually has very little to do with identity. Notwithstanding my emphasizing in the article the potential for OAuth to protect APIs behind which sit user profile data, OAuth is an authentication and authorization framework for generic APIs, i.e. it says nothing about the nature and syntax of APIs it protects. The APIs could be identity centric, or they could be 'waste flow' metrics from a sewer pipe. For the most part, OAuth 2.0 doesn't really care about the specifics of the data flowing over the APIs.
Additionally, while OAuth 2.0 defines a protocol by which a token associated with a particular user can be 1) issued by one actor, 2) delivered over the network and 3) consumed and validated by another actor (which is topologically identical to how web SSO works) the semantics of the token in question are not "this user just logged in to me", but rather something more like "whomever can present this token is authorized to read the sewer waste flow data." Consequently, despite attempts to use OAuth 2.0 to enable an SSO model, it wasn't designed for that out of the box and can only be stretched that way with arm twisting and eye squinting.
OpenID Connect is a freshly ratified standard from the OpenID Foundation that provides identity semantics and constructs on top of OAuth 2.0. Connect logically layers identity onto the OAuth base - stipulating how to use OAuth to 'do' identity, as opposed to other non-identity centric applications that are possible.
Connect introduces two notable identity constructs - the first is an 'identity token', the transfer of which from one network actor to another enables web SSO. Unlike the tokens that OAuth provides, Connect's identity token has the necessary semantic (and syntax) required for federated authentication. Think of Connect's id_token as a young and hip version of SAML's Assertion - no XML in sight and having the latest iPhone and not a seven-year-old clamshell feature phone.
Connect's second identity construct is the definition of a specific REST (of course) API for identity attributes - the so-called UserInfo endpoint. By calling this API, a client application can obtain for itself the sorts of identity attributes it would otherwise typically collect in a registration form - email, name, address etc.
Connect's id_token and UserInfo provide an application-standardized mechanism to obtain the two categories of identity attributes that are most problematic to deal with directly - authentication state and identity attributes. By obtaining authentication state through Connect and not directly, the client can get out of the "password issuance and management" business. And by obtaining attributes through Connect, the client can mitigate the "form fill" drop off or "everybody lives in 90210 zip" effects.
OAuth 2.0 is important and useful, though not for identity applications. For those, you need OpenID Connect. So, again, apologies for any misunderstanding created by the title of the OAuth 2.0 article. Those responsible have been sacked.