Identity 3: OAuth

Post date: May 29, 2011 2:21:48 PM

Background

OAuth emerged from the social web, originally motivated by a desire to mitigate the so-called “password anti-pattern” in which a user, in order to authorize a third-party site to access their Facebook data, would be asked to provide their Facebook password to that third-party site. The first version, OAuth 1.0, allowed a user to specify such permissions without divulging their Facebook credentials to any entity other than Facebook.

OAuth 2.0 still supports this original delegated authorization use case from the consumer web but is now relevant to enterprises and the Cloud as well—which is arguably more about authentication than authorization. For instance, Salesforce uses OAuth to protect the many APIs they offer up to their enterprise customers. Enterprises themselves are using OAuth to protect the APIs they offer their partners and customers as well as internal clients in “private cloud” models.

How it Works

A key technical underpinning of the Cloud are Application Programming Interfaces (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, 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, respectively, provided means for SOAP API clients to obtain authentication credentials and attach those credentials to the API queries, RESTful API clients were presumed to bear the direct burden of managing the credentials used for authenticating to the APIs, as well as those APIs defined by different mechanisms for that authentication.

OAuth 2.0 (undergoing standardization in the Internet Engineering Task Force (IETF)) remedies this authentication gap by providing to the RESTful API world (whether enterprise, cloud, or social network hosted) the same functionality as do WS-Trust and WS-Security for SOAP web services--namely standardized mechanisms by which a client of such an API can 'get a token' as well as 'use a token' (e.g present the token on its API call to authenticate itself).

https://www.pingidentity.com/resource-center/oauth-essentials.cfm