OAuth

The OAuth logo, designed by Chris Messina

OAuth is an open standard for authorization, commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.^[1] Generally, OAuth provides to clients a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.^[2]

OAuth is a service that is complementary to and distinct from OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0.

History

OAuth began in November 2006 when Blaine Cook was developing the Twitter OpenID implementation. Meanwhile, Ma.gnolia needed a solution to allow its members with OpenIDs to authorize Dashboard Widgets to access their service. Cook, Chris Messina and Larry Halff from Magnolia met with David Recordon to discuss using OpenID with the Twitter and Ma.gnolia APIs to delegate authentication. They concluded that there were no open standards for API access delegation.

The OAuth discussion group was created in April 2007, for the small group of implementers to write the draft proposal for an open protocol. DeWitt Clinton from Google learned of the OAuth project, and expressed his interest in supporting the effort. In July 2007 the team drafted an initial specification. Eran Hammer joined and coordinated the many OAuth contributions, creating a more formal specification. On December 4, 2007, the OAuth Core 1.0 final draft was released.^[3]

At the 73rd Internet Engineering Task Force(IETF) meeting in Minneapolis in November 2008, an OAuth BoF was held to discuss bringing the protocol into the IETF for further standardization work. The event was well attended and there was wide support for formally chartering an OAuth working group within the IETF.

The OAuth 1.0 protocol was published as RFC 5849, an informational Request for Comments, in April 2010.

Since August 31, 2010, all third party Twitter applications have been required to use OAuth.^[4]

The OAuth 2.0 framework was published as RFC 6749, and the Bearer Token Usage as RFC 6750, both standards track Requests for Comments, in October 2012.

OAuth 2.0

OAuth 2.0 is the next evolution of the OAuth protocol and is not backwards compatible with OAuth 1.0. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. The specification and associated RFCs are developed by the IETF OAuth WG;^[5] the main framework was published in October 2012. (It was expected to be finalized by the end of 2010, according to Eran Hammer.^[6] However, due to discordant views about the evolution of OAuth, Hammer left the working group.^[7])

Facebook's Graph API only supports OAuth 2.0.^[8] Google supports OAuth 2.0 as the recommended authentication mechanism for all of its APIs.^[9] As of 2011 Microsoft^[10] has added OAuth 2.0 experimental support to their APIs.

The OAuth 2.0 Framework^[11] and Bearer Token Usage^[12] were published in October 2012. Other documents are still being worked on within the OAuth working group.

Security

On April 23, 2009, a session fixation security flaw in the 1.0 protocol was announced. It affects the OAuth authorization flow (also known as "3-legged OAuth") in OAuth Core 1.0 Section 6.^[13] Version 1.0a of the OAuth Core protocol was issued to address this issue.^[14]

OAuth 2.0 doesn't support signature, encryption, channel binding, or client verification. It relies completely on TLS for some degree of confidentiality and server authentication.^[15][16]

OAuth 2.0 has had numerous security flaws exposed in implementations.^[17] The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.^[18][19]

In January 2013, the Internet Engineering Task Force published a number of threat models for OAuth 2.0.^[20] Among them was one called "Open Redirector"; in the spring of 2014 this was described under the name "Covert Redirect" by Wang Jing.^{[21][22][23][24]}

Possibly the most devastating OAuth security failure is phishing vulnerability:^[25] every web site using OAuth is visually (but not technically) asking end users for their username and password of their master identity, which prevents ordinary users from understanding that they should not type those in should they encounter an attacker's web site that visually emulates this process to steal credentials. 2FA/two-step does not prevent this attack, because the phishing site can steal that as well (and use it right away).

Non-interoperability

Because OAuth 2.0 is more of a framework than a defined protocol, OAuth 2.0 implementations are less likely to be naturally interoperable with any other OAuth 2.0 implementations. Further deployment profiling and specification is required for any interoperability.^[26]

Uses

OAuth can be used as an authorizing mechanism to consume secured RSS/ATOM feeds. Consumption of RSS/ATOM feeds that require authentication has always been an issue. For example, an RSS feed from a secured Google Site cannot be consumed using Google Reader. Instead, three-legged OAuth can be used to authorize Google Reader to access the RSS feed from that Google Site.

OpenID vs. pseudo-authentication using OAuth

The following diagrams highlight the differences between using OpenID and OAuth for authentication. With OpenID, the process starts with the application asking the user for their identity (basically a log-in request by the application, to which the user typically provides an OpenID URI rather than actual credentials). In the case of OAuth, the application specifically requests a limited access OAuth Token to access the APIs on the user's behalf (which typically explicitly names the particular rights requested, and does not require the user to enter credentials at all). If the user can grant that access, the application can retrieve the unique identifier for establishing the profile (identity) using the APIs. In either case, the access to the Identity Provider will involve authentication to the Identity Provider, unless some session is already in effect. The result in the OpenID case is that the application allows the user access, because it trusts the OpenID Identity provider. The result in the OAuth case is that the API provider allows the application access because it trusts its own valet keys.

Controversy

In July 2012, Eran Hammer resigned his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specification. Hammer pointed to a conflict between the web and enterprise cultures, citing the IETF as a community that is "all about enterprise use cases", that is "not capable of simple." What is now offered is a blueprint for an authorization protocol, he says, and "that is the enterprise way", providing a "whole new frontier to sell consulting services and integration solutions."^[7]

In comparing OAuth 2.0 with 1.0, Hammer points out that it has become "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure." He explains how architectural changes for 2.0 unbound tokens from clients, removed all signatures and cryptography at a protocol level and added expiring tokens because tokens couldn't be revoked while complicating the processing of authorization. Numerous items were left unspecified or unlimited in the specification because "as has been the nature of this working group, no issue is too small to get stuck on or leave open for each implementation to decide."^[7]

Hammer later gave a presentation at &Yet elaborating on his views.^[27]

David Recordon later also removed his name from the specifications for unspecified reasons. Dick Hardt took over the editor role, and the framework was published in October 2012.^[11]

See also

• List of OAuth providers
• OpenID
• DataPortability
• Mozilla Persona
• SAML
• User-Managed Access
• FIDO

References

External links

• The OAuth 1.0 Protocol (RFC 5849)
• The OAuth 2.0 Authorization Framework (RFC 6749)
• The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750)
• "OAuth.net". 
• "OAuth Working Group's Mailing List". 
• "OAuth Code Library Support".  on Google Groups
• "OAuth Beginner's Guide and Resource Center". Hueniverse. 
• "Google OAuth & Federated Login Research". 
• "Yahoo! OAuth Quick Start Guide". 
• "LIVE Demo of OAuth with Google, Yahoo". 
• "oAuth Live demo and get php source code from github". 
• oAuth End points cheat sheet