OAuth

The OAuth logo, designed by Chris Messina

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.[1] This mechanism is used by companies such as Amazon,[2] Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.

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.[3]

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. OAuth is also distinct from XACML, which is an authorization policy standard. OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies (e.g. managers can view documents in their region).

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.[4]

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.[5]

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 not backwards compatible with OAuth 1.0. OAuth 2.0 provides specific authorization flows for web applications, desktop applications, mobile phones, and smart devices. The specification and associated RFCs are developed by the IETF OAuth WG;[6] the main framework was published in October 2012.

Facebook's Graph API only supports OAuth 2.0.[7] Google supports OAuth 2.0 as the recommended authorization mechanism for all of its APIs.[8] Microsoft[9] also supports OAuth 2.0 for various APIs and its Azure Active Directory service, which is used to secure many Microsoft and third party APIs.

The OAuth 2.0 Framework[10] and Bearer Token Usage[11] were published in October 2012.

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.[12] Version 1.0a of the OAuth Core protocol was issued to address this issue.[13]

OAuth 2.0 does not support signature, encryption, channel binding, or client verification. It relies completely on TLS for some degree of confidentiality and server authentication.[14][15]

OAuth 2.0 has had numerous security flaws exposed in implementations.[16] 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.[17][18]

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

Possibly the most devastating OAuth security failure is phishing vulnerability:[24] 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. Traditional two-factor authentication (using one-time passwords) does not prevent this attack, because the phishing site can steal that as well, using it immediately (note that Universal 2nd Factor tokens aren't vulnerable to this specific type of attack).

In April–May 2017, about one million users of Gmail (less than 0.1% of users as of May 2017) were targeted by an OAuth-based phishing attack, receiving an email purporting to be from a colleague, employer or friend wanting to share a document on Google Docs.[25] Those who clicked on the link within the email were directed to sign in and allow a potentially malicious third-party program called "Google Apps" access their "email account, contacts and online documents".[25] Within "approximately one hour",[25] the phishing attack was stopped by Google, who advised those who had given "Google Apps" access to their email to revoke such access and change their passwords.

Non-interoperability

Because OAuth 2.0 is more of a framework than a defined protocol, one OAuth 2.0 implementation is less likely to be naturally interoperable with another OAuth 2.0 implementation. 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 could not have been consumed using Google Reader. Instead, three-legged OAuth would have been used to authorize that RSS client to access the feed from the Google Site.

OAuth and other standards

OpenID vs. pseudo-authentication using OAuth

OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication. The following diagrams highlight the differences between using OpenID (specifically designed as an authentication protocol) and OAuth for authentication.

The communication flow in both processes is similar:

  1. (Not pictured) The user requests a resource or site login from the application.
  2. The site sees that the user is not authenticated. It formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
  3. The user's browser requests the redirect URL for the identity provider, including the application's request
  4. If necessary, the identity provider authenticates the user (perhaps by asking them for their username and password)
  5. Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
  6. The user's browser requests the redirect URL that goes back to the application, including the identity provider's response
  7. The application decodes the identity provider's response, and carries on accordingly.
  8. (OAuth only) The response includes an access token which the application can use to gain direct access to the identity provider's services on the user's behalf.

The crucial difference is that in the OpenID authentication use case, the response from the identity provider is an assertion of identity; while in the OAuth authorization use case, the identity provider is also an API provider, and the response from the identity provider is an access token that may grant the application ongoing access to some of the identity provider's APIs, on the user's behalf. The access token acts as a kind of "valet key" that the application can include with its requests to the identity provider, which prove that it has permission from the user to access those APIs.

Because the identity provider typically (but not always) authenticates the user as part of the process of granting an OAuth access token, it's tempting to view a successful OAuth access token request as an authentication method itself. However, because OAuth was not designed with this use case in mind, making this assumption can lead to major security flaws.[27]

OAuth and XACML

XACML is a policy-based, attribute-based access control authorization framework. It provides:

  • An access control architecture.
  • A policy language with which to express a wide range of access control policies including policies that can use consents handled / defined via OAuth.
  • A request / response scheme to send and receive authorization requests.

XACML and OAuth can be combined together to deliver a more comprehensive approach to authorization. OAuth does not provide a policy language with which to define access control policies. XACML can be used for its policy language.

Where OAuth focuses on delegated access (I, the user, grant Twitter access to my Facebook wall), and identity-centric authorization, XACML takes an attribute-based approach which can consider attributes of the user, the action, the resource, and the context (who, what, where, when, how). With XACML it is possible to define policies such as

  • Managers can view documents in their department
  • Managers can edit documents they own in draft mode

XACML provides more fine-grained access control than OAuth does. OAuth is limited in granularity to the coarse functionality (the scopes) exposed by the target service. As a result, it often makes sense to combine OAuth and XACML together where OAuth will provide the delegated access use case and consent management and XACML will provide the authorization policies that work on the applications, processes, and data.

Lastly, XACML can work transparently across multiple stacks (APIs, web SSO, ESBs, home-grown apps, databases...). OAuth focuses exclusively on HTTP-based apps.

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."[28]

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."[28]

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

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.[10]

See also

References

  1. ↑ Whitson Gordon. "Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook". Retrieved 2016-05-15.
  2. ↑ Amazon & OAuth 2.0
  3. ↑ "RFC 6749 - The OAuth 2.0 Authorization Framework". Retrieved 2016-05-15.
  4. ↑ "OAuth Core 1.0". December 4, 2007. Retrieved October 16, 2014.
  5. ↑ Chris Crum (2010-08-31). "Twitter Apps Go OAuth Today". WebProNews.com. Retrieved 2017-07-31.
  6. ↑ "Web Authorization Protocol (oauth)". IETF. Retrieved May 8, 2013.
  7. ↑ "Authentication - Facebook Developers". developers.facebook.com.
  8. ↑ "Google Accounts Authentication and Authorization". developers.google.com.
  9. ↑ Danny Strockis (2016-08-08). "v2.0 Protocols - OAuth 2.0 Authorization Code Flow". docs.microsoft.com.
  10. 1 2 "RFC6749 - The OAuth 2.0 Authorization Framework". Dick Hardt. October 2012. Retrieved 10 October 2012.
  11. ↑ "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Michael Jones, Dick Hardt. October 2012. Retrieved 10 October 2012.
  12. ↑ "OAuth Security Advisory: 2009.1". 2009-04-23. Retrieved 2009-04-23.
  13. ↑ OAuth Core 1.0a
  14. ↑ "Is OAuth 2.0 Bad for the Web?". 2010-09-20. Retrieved 2010-09-21.
  15. ↑ "an unwarranted bashing of Twitter's oAuth". 2011-08-03. Retrieved 2011-08-03.
  16. ↑ "Hacking Facebook with OAuth 2.0 and Chrome". 2013-02-12. Retrieved 2013-03-06.
  17. ↑ "Re: OAUTH-WG OAuth2 attack surface..." 2013-02-28. Retrieved 2013-03-06.
  18. ↑ "OAuth1, OAuth2, OAuth...?". 2013-03-01. Retrieved 2013-03-06.
  19. ↑ OAuth 2.0 Threat Model and Security Considerations. Internet Engineering Task Force. Accessed January 2015.
  20. ↑ "OAuth Security Advisory: 2014.1 "Covert Redirect"". OAuth. 4 May 2014. Retrieved 10 November 2014.
  21. ↑ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 May 2014. Retrieved 10 November 2014.
  22. ↑ "Math student detects OAuth, OpenID security vulnerability". Phys.org. 3 May 2014. Retrieved 11 November 2014.
  23. ↑ "Covert Redirect". Tetraph. 1 May 2014. Retrieved 10 November 2014.
  24. ↑ "Serious security flaw in OAuth, OpenID discovered". CNET. Retrieved 2016-05-15.
  25. 1 2 3 "Google Docs phishing email 'cost Minnesota $90,000'". BBC News. 8 May 2017. Archived from the original on 8 May 2017.
  26. ↑ Dick Hardt, ed. "Interoperability". The OAuth 2.0 Authorization Framework. IETF. sec. 1.8. doi:10.17487/RFC6749. 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."
  27. ↑ "End User Authentication with OAuth 2.0". OAuth Community Site. Retrieved 8 March 2016.
  28. 1 2 "OAuth 2.0 and the Road to Hell". Eran Hammer. 28 July 2012. Retrieved 17 January 2018.
  29. ↑ "OAuth 2.0 - Looking Back and Moving On". Eran Hammer. 23 October 2012. Retrieved 22 November 2012.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.