OAuth is an open standard for authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
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 October 3, 2007, the OAuth Core 1.0 final draft was released.
At the 73rd Internet Engineering Task Force 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.
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; the main framework was published in October 2012. (It was expected to be finalized by the end of 2010, according to Eran Hammer. However, due to discordant views about the evolution of OAuth, Hammer left the working group.)
Facebook's new Graph API only supports OAuth 2.0. Google supports OAuth 2.0 as the recommended authentication mechanism for all of its APIs. As of 2011 Microsoft has added OAuth 2.0 experimental support to their APIs.
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. Version 1.0a of the OAuth Core protocol was issued to address this issue.
OAuth 2.0 has had numerous security flaws exposed in implementations. 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.
Because OAuth 2.0 is more like a framework rather than a defined protocol, any OAuth 2.0 implementation is unlikely to naturally be interoperable with any other OAuth 2.0 implementation. Further deployment profiling and specification is required for any interoperability.
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 can not be consumed using Google Reader. Instead, 3-Legged OAuth can be used to authorize Google Reader to access the RSS feed from that Google Site.
Abuse of OAuth for Internet data mining
A growing number of social networking services promote OAuth logins to the dominant social networks (Facebook, Twitter, etc.) as the primary authentication method, over "traditional" email confirmation type processes. Users of such practices include Klout, Kred, Foursquare, and others. The permissions granted typically permit the authorized application to download the entire social data stream belonging to the user, which is stored for data-mining purposes by the application provider. By facilitating such use, OAuth is acting as a component in a social engineering type scam where users of the application probably do not realize the extent of the data they are sharing.
The use of OAuth logins to social networks for "authentication" permits the application provider to legitimately circumvent the often significant restrictions on API use put in place by social network providers to prevent large-scale data extraction. For example, Twitter only permits an authenticated login to perform around 350 API calls per hour (the exact number depends on the application). This throttle makes it essentially impossible to download large quantities of data despite the existence of an open API. However, if an application is able to acquire credentials for just 1,000 distinct users, for example, then it can make 350,000 API calls per hour, a significant increase. Obviously what can be done via OAuth authentication depends on the permissions granted within the OAuth consumer token --- however, many social networking services request the maximal permission set possible and do not provide functionality for the user to remove items from the permission set.
List of OAuth service providers
|Service provider||OAuth protocol|
|deviantART||2.0 drafts 10 and 15|
|2.0 draft 12|
|Google App Engine||1.0a |
|Intel Cloud Services||2.0|
|Microsoft (Hotmail, Windows Live, Messenger, Xbox)||2.0|
|OpenLink Data Spaces||1.0|
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 (valet key) to access the APIs (enter the house) 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.
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."
Despite this, it has been noted[unreliable source?] that OAuth 2.0 doesn't fit enterprise cultures either. Management is unlikely to want to offer an external API upon a framework which is non-interoperable and presents unquantifiable risk.[original research?] The essential authentication design of OAuth 2.0 also clashes with the needs of enterprise level integration, making usage of a third party API authorized by OAuth 2.0 "difficult if not outright impossible."
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 authorisation. 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."
Eran later gave a presentation at &yet elaborating on his views.
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.
- Chris Crum (2010-08-31). "Twitter Apps Go OAuth Today ". WebProNews.com. Retrieved 2011-03-14.
- "Web Authorization Protocol (oauth)". IETF. Retrieved May 8, 2013.
- Eran Hammer (2010-05-15). "Introducing OAuth 2.0". Retrieved 2011-03-14.
- "OAuth 2.0 and the Road to Hell". Eran Hammer. 28 July 2012. Retrieved 16 August 2012.
- "Authentication - Facebook Developers". developers.facebook.com.
- "Google Accounts Authentication and Authorization". developers.google.com.
- Dare Obasanjo (2011-05-04). "Announcing Support for OAuth 2.0". windowsteamblog.com.
- "RFC6749 - The OAuth 2.0 Authorization Framework". Dick Hardt. October 2012. Retrieved 10 October 2012.
- "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Michael Jones, Dick Hardt. October 2012. Retrieved 10 October 2012.
- "OAuth Security Advisory: 2009.1". 2009-04-23. Retrieved 2009-04-23.
- OAuth Core 1.0a
- "Is OAuth 2.0 Bad for the Web?". 2010-09-20. Retrieved 2010-09-21.
- "an unwarranted bashing of Twitter’s oAuth". 2011-08-03. Retrieved 2011-08-03.
- "Hacking Facebook with OAuth 2.0 and Chrome". 2013-02-12. Retrieved 2013-03-06.
- "Re: OAUTH-WG OAuth2 attack surface....". 2013-02-28. Retrieved 2013-03-06.
- "OAuth1, OAuth2, OAuth...?". 2013-03-01. Retrieved 2013-03-06.
- Dick Hardt, ed. "Interoperability". The OAuth 2.0 Authorization Framework. IETF. sec. 1.8. RFC 6749. https://tools.ietf.org/html/rfc6749#section-1.8. Retrieved 8 May 2013. "as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations."
- "OAuth". Develop AllPlayers.com. Retrieved 2013-09-21.
- "Home - Login with Amazon Developer Center". Login.amazon.com. Retrieved 2013-09-21.
- / (2012-09-11). "api/sections/authentication.md at master 路 37signals/api 路 GitHub". Github.com. Retrieved 2013-09-21.
- "Box Platform Developer Documentation". Developers.box.com. Retrieved 2013-09-21.
- Retry-After. "Core API - endpoint reference". Dropbox. Retrieved 2013-09-21.
- "Google App Engine — Google Developers" (in (Italian)). Developers.google.com. Retrieved 2013-09-21.
- "Authentication | LinkedIn Developer Network". Developer.linkedin.com. 2011-01-12. Retrieved 2013-09-21.
- "2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィ デベロッパーセンター)". Developer.mixi.co.jp. Retrieved 2013-09-21.
- "ODS: ODS as an OAuth Provider". Web.ods.openlinksw.com. 1970-01-01. Retrieved 2013-09-21.
- "Plurk API 2.0". Plurk.com. Retrieved 2013-09-21.
- / (2013-08-12). "OAuth2 路 reddit/reddit Wiki 路 GitHub". Github.com. Retrieved 2013-09-21.
- "POST oauth2/token | Twitter Developers". Dev.twitter.com. 2013-03-11. Retrieved 2013-09-21.
- "OAuth 2.0 Authentication | Viadeo API". Dev.viadeo.com. Retrieved 2013-09-21.
- "Authentication | XING Developer". Dev.xing.com. 1970-01-01. Retrieved 2013-09-21.
- "OAuth - A great way to cripple your API". Insane Coding. March 19, 2013. Retrieved March 21, 2013.
- "OAuth 2.0 - Looking Back and Moving On". Eran Hammer. 23 October 2012. Retrieved 22 November 2012.
- 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 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".
- "OAuth Checklist".
- "LIVE Demo of OAuth with Google, Yahoo".
- "oAuth Live demo and get php source gode from github".
- oAuth End points cheat sheet