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/

Answer 2

An ID token can be signed by the authentication server. A client application can verify the signature to confirm that the end-user has been authenticated by the very authentication server. Access token + protected resource call do not provide such a mechanism.

In addition, OpenID Connect has introduced other mechanisms related to authentication such as:

1. Authentication Context Class Reference
2. Maximum Authentication Age
3. sub claim in claims request parameter

to satisfy higher-level security requirements by governments.

Read OpenID Connect Core 1.0 and other related specifications. Also, you may find "Authorization interaction" helpful as a summary about what OpenID Connect has added to control end-user authentication.

Answer 3

OAuth 2.0 is about granting a third party limited access to a resource. The RFC starts with

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service...

OpenID Connect is about establishing an end-user's identity. The OpenID Connect Core spec starts with

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server...

In OAuth 2.0, when a resource server receives a request containing an access token, the resource server knows that the resource owner has granted a third party access to a resource. The access token represents this approval but it does not identify the third party who is presenting it.

If a company thinks someone like Salesforce or Google is better equiped than they are to manage user accounts, passwords, digital certificates, etc., the company could use OpenID Connect to essentially "outsource" that responsibility to an OpenID Connect Provider. When the company receives an id token in the context of an OpenID Connect flow, it knows that the provider has authenticated the end-user and established the user's identity.

OpenID Connect has repurposed the OAuth 2.0 flows so that the identity of an end-user can be established.