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 protocol 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 protocol 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 on a profile of OAuth, and provides additional capabilities in conveying the identity of the user using the application – and not just the application itself.
A key technical underpinning of the cloud is the Application Programming Interface (API). APIs provide consistent methods for outside entities to access and manipulate cloud-hosted services. More and more, cloud data will move through APIs rather than the browser. For SOAP-based APIs (Simple Object Access Protocol), standards like WS-Trust and WS-Security define how clients of the APIs are authenticated. RESTful services, on the other hand, do not have equivalent standardized functions.
While WS-Trust and WS-Security provided means for SOAP API clients to obtain authentication credentials and attach those credentials to the API queries, RESTful API clients managed the credentials used for authenticating to the APIs, as well as those APIs defined by different mechanisms for that authentication.
OAuth 2.0 provides the same functionality the RESTful API world as WS-Trust and WS-Security provide for SOAP web services. Specifically, providing standardized mechanisms to allow API clients to 'get' and 'use' tokens; for example, present the token on its API call to authenticate itself.