OAuth emerged from the social web, originally motivated by a desire to allow users to specify authorization permissions without divulging social media credentials, commonly known as the password anti-pattern.
OAuth 2.0 supports the delegated authorization use case from the consumer web but is now relevant to enterprises and the cloud. For instance, Salesforce.com uses OAuth to protect the many APIs they offer their enterprise customers. Enterprises are using OAuth to protect the APIs they offer their partners and customers as well as internal clients in “private cloud” models.
OAuth 2.0 is explicitly designed to support a variety of different client types, which access REST APIs. This includes both applications running on web servers within the enterprise calling out to the cloud as well as applications running on employee or customer mobile devices. OAuth supports this variety of client types by defining multiple mechanisms for getting a token where the different mechanisms acknowledge the client type constraints.
OpenID Connect is built a profile of OAuth, and provides additional capabilities in conveying the identity of the user using the application – and not just the application itself.