Jump to content

OAuth

From Wikipedia, the free encyclopedia
For MediaWiki's (the software used by Wikipedia) OAuth support, seemw:Help:OAuth

Unofficial logo designed byChris Messina
Latest version2.0
OrganizationInternet Engineering Task Force
WebsiteHardt, Dick (October 2012)."The OAuth 2.0 Authorization Framework".

OAuth(short foropen authorization[1][2]) is an open standard for accessdelegation,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.[3][4]This mechanism is used by companies such asAmazon,[5]Google,Meta Platforms,Microsoft,andTwitterto permit users to share information about their accounts with third-party applications or websites.

Generally, the OAuth protocol provides a way for resource owners to provide aclient applicationwith secure delegated access to server resources. It specifies a process for resource owners to authorize third-party access to their server resources without providing credentials. Designed specifically to work withHypertext Transfer Protocol(HTTP), OAuth essentially allowsaccess tokensto 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]

History

[edit]
Authorization flow without Oauth.
A hypothetical authorization flow where login information is shared with a third-party application. This poses many security risks which can be prevented by the use of OAuth authorization flows.
A high-level overview of Oauth 2.0 authorization flow.
A high-level overview of Oauth 2.0 flow. The resource owner credentials are used only on the authorization server, but not on the client (e.g. the third-party app).

OAuth began in November 2006 whenBlaine Cookwas developing theTwitterOpenIDimplementation. Meanwhile,Ma.gnolianeeded a solution to allow its members with OpenIDs to authorizeDashboard Widgetsto access their service. Cook,Chris Messinaand Larry Halff from Magnolia met withDavid Recordonto discuss using OpenID with the Twitter and MagnoliaAPIsto delegate authentication. They concluded that there were no open standards for API access delegation.[6]

The OAuthdiscussion groupwas created in April 2007, for a small group of implementers to write the draft proposal for an open protocol. DeWitt Clinton fromGooglelearned 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 4 December 2007, the OAuth Core 1.0 final draft was released.[7]

At the 73rdInternet Engineering Task Force(IETF) meeting inMinneapolisin November 2008, an OAuthBoFwas 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 informationalRequest for Comments,in April 2010. Since 31 August 2010, all third party Twitter applications have been required to use OAuth.[8]

The OAuth 2.0 framework was published considering additional use cases and extensibility requirements gathered from the wider IETF community. Albeit being built on the OAuth 1.0 deployment experience, OAuth 2.0 is not backwards compatible with OAuth 1.0. OAuth 2.0 was published as RFC 6749 and the Bearer Token Usage[clarification needed]as RFC 6750, both standards track Requests for Comments, in October 2012.[2][9]

The OAuth 2.1 Authorization Framework is in draft stage and consolidates the functionality in the RFCs OAuth 2.0, OAuth 2.0 for Native Apps, Proof Key for Code Exchange, OAuth 2.0 for Browser-Based Apps, OAuth Security Best Current and Bearer Token Usage.[10]

Security issues

[edit]

OAuth 1.0

[edit]

On 23 April 2009, asession fixationsecurity 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.[11] Version 1.0a of the OAuth Core protocol was issued to address this issue.[12]

OAuth 2.0

[edit]

In January 2013, the Internet Engineering Task Force published a threat model for OAuth 2.0.[13]Among the threats outlined is one called "Open Redirector"; in early 2014, a variant of this was described under the name "Covert Redirect" by Wang Jing.[14][15][16][17]

OAuth 2.0 has been analyzed using formal web protocol analysis. This analysis revealed that in setups with multiple authorization servers, one of which is behaving maliciously, clients can become confused about the authorization server to use and may forward secrets to the malicious authorization server (AS Mix-Up Attack).[18]This prompted the creation of a newbest current practiceinternet draft that sets out to define a new security standard for OAuth 2.0.[19]Assuming a fix against the AS Mix-Up Attack in place, the security of OAuth 2.0 has been proven under strong attacker models using formal analysis.[18]

One implementation of OAuth 2.0 with numerous security flaws has been exposed.[20]

In April and May 2017, about one million users ofGmail(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.[21]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" to access their "email account, contacts and online documents".[21]Within "approximately one hour",[21]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.

In the draft of OAuth 2.1 the use of the PKCE extension for native apps has been recommended to all kinds of OAuth clients, including web applications and other confidential clients in order to prevent malicious browser extensions from performing OAuth 2.0 code injection attacks.[10]

Types

[edit]

OAuth framework specifies several grant types for different use cases. Some of the most common OAuth grant types are:[22]

  • Authorization Code
  • PKCE
  • Client Credentials
  • Device Code
  • Refresh Token

Uses

[edit]

Facebook'sGraph APIonly supports OAuth 2.0.[23]Googlesupports OAuth 2.0 as the recommended authorization mechanism for all of itsAPIs.[24]Microsoftalso supports OAuth 2.0 for various APIs and its Azure Active Directory service,[25]which is used to secure many Microsoft and third party APIs.

OAuth can be used as an authorizing mechanism to access securedRSS/Atomfeeds. Access to RSS/ATOM feeds that require authentication has always been an issue. For example, an RSS feed from a securedGoogle Sitecould not have been accessed usingGoogle 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

[edit]

OAuth is a service that is complementary to and distinct fromOpenID.OAuth is unrelated toOATH,which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related toOpenID Connect(OIDC), since OIDC is an authentication layer built on top of OAuth 2.0. OAuth is also unrelated toXACML,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).

OpenID vis-à-vis pseudo-authentication using OAuth

[edit]

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

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 makes a request to 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 OpenIDauthenticationuse case, the response from the identity provider is an assertion of identity; while in the OAuthauthorizationuse case, the identity provider is also anAPIprovider, 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 is 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]

OpenID vs. pseudo-authentication using OAuth

OAuth and XACML

[edit]

XACMLis a policy-based,attribute-based access controlauthorization framework. It provides:

  • Anaccess 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 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

[edit]

Eran Hammer resigned from his role of lead author for the OAuth 2.0 project, withdrew from theIETF working group,and removed his name from the specification in July 2012. Hammer cited a conflict between web and enterprise cultures as his reason for leaving, noting that IETF is a community that is "all about enterprise use cases" and "not capable of simple". "What is now offered is a blueprint for an authorization protocol", he noted, "that is the enterprise way", providing a "whole new frontier to sell consulting services and integration solutions".[28]In comparing OAuth 2.0 with OAuth 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 could not 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]

David Recordonlater also removed his name from the specifications for unspecified reasons.[citation needed]Dick Hardttook over the editor role, and the framework was published in October 2012.[2]

David Harris, author of the email clientPegasus Mail,has criticised OAuth 2.0 as "an absolute dog's breakfast", requiring developers to write custom modules specific to each service (Gmail, Microsoft Mail services, etc.), and to register specifically with them.[29]

See also

[edit]

References

[edit]
  1. ^"Open Authorization - Glossary | CSRC".csrc.nist.gov.
  2. ^abcdHardt, Dick (October 2012). Hardt, D (ed.)."RFC6749 - The OAuth 2.0 Authorization Framework".Internet Engineering Task Force.doi:10.17487/RFC6749.Archivedfrom the original on 15 October 2012.Retrieved10 October2012.{{cite journal}}:Cite journal requires|journal=(help)
  3. ^Whitson, Gordon."Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook".Lifehacker.Archivedfrom the original on 24 April 2014.Retrieved15 May2016.
  4. ^Henry, Gavin (January 2020)."Justin Richer on OAuth".IEEE Software.37(1): 98–100.doi:10.1109/MS.2019.2949648.ISSN0740-7459.
  5. ^"Amazon & OAuth 2.0".Archivedfrom the original on 8 December 2017.Retrieved15 December2017.
  6. ^"Introduction".oauth.net.Archivedfrom the original on 21 November 2018.Retrieved21 November2018.
  7. ^"OAuth Core 1.0".4 December 2007.Archivedfrom the original on 25 November 2015.Retrieved16 October2014.
  8. ^Chris Crum (31 August 2010)."Twitter Apps Go OAuth Today".WebProNews.com.Archivedfrom the original on 31 July 2017.Retrieved31 July2017.
  9. ^Jones, Michael; Hardt, Dick (October 2012)."RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage".Internet Engineering Task Force.doi:10.17487/RFC6750.Archivedfrom the original on 15 October 2012.Retrieved10 October2012.{{cite journal}}:Cite journal requires|journal=(help)
  10. ^abLodderstedt, Torsten; Hardt, Dick; Parecki, Aaron (13 October 2012)."The OAuth 2.1 Authorization Framework".tools.ietf.org.Retrieved22 November2020.
  11. ^"OAuth Security Advisory: 2009.1".oauth.net.23 April 2009.Archivedfrom the original on 27 May 2016.Retrieved23 April2009.
  12. ^"OAuth Core 1.0a".oauth.net.Archivedfrom the original on 30 June 2009.Retrieved17 July2009.
  13. ^Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (January 2013). Lodderstedt, T (ed.)."RFC6819 - OAuth 2.0 Threat Model and Security Considerations".Internet Engineering Task Force.doi:10.17487/RFC6819.Archivedfrom the original on 30 June 2020.Retrieved29 June2020.[rfc:6819 OAuth 2.0 Threat Model and Security Considerations]. Internet Engineering Task Force. Accessed January 2015.
  14. ^"OAuth Security Advisory: 2014.1" Covert Redirect "".oauth.net.4 May 2014.Archivedfrom the original on 21 November 2015.Retrieved10 November2014.
  15. ^"Serious security flaw in OAuth, OpenID discovered".CNET.2 May 2014.Archivedfrom the original on 2 November 2015.Retrieved10 November2014.
  16. ^"Math student detects OAuth, OpenID security vulnerability".Phys.org. 3 May 2014.Archivedfrom the original on 6 November 2015.Retrieved11 November2014.
  17. ^"Covert Redirect".Tetraph. 1 May 2014.Archivedfrom the original on 10 March 2016.Retrieved10 November2014.
  18. ^abFett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). "A Comprehensive Formal Security Analysis of OAuth 2.0".Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security.New York, New York, USA: ACM Press. pp. 1204–1215.arXiv:1601.01229.Bibcode:2016arXiv160101229F.doi:10.1145/2976749.2978385.ISBN9781450341394.S2CID1723789.
  19. ^Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel (8 July 2019)."OAuth 2.0 Security Best Current Practice".Internet Engineering Task Force.Archivedfrom the original on 17 January 2020.Retrieved29 July2019.
  20. ^"Hacking Facebook with OAuth 2.0 and Chrome".12 February 2013.Archivedfrom the original on 23 April 2016.Retrieved6 March2013.
  21. ^abc"Google Docs phishing email 'cost Minnesota $90,000'".BBC News.8 May 2017.Archivedfrom the original on 30 June 2020.Retrieved29 June2020.
  22. ^"Oauth Grant Types".Oauth.net.Retrieved6 December2023.
  23. ^"Authentication - Facebook Developers".Facebook for Developers.Archivedfrom the original on 23 January 2014.Retrieved5 January2020.
  24. ^"Using OAuth 2.0 to Access Google APIs | Google Identity Platform".Google Developers.Archivedfrom the original on 4 January 2020.Retrieved4 January2020.
  25. ^"v2.0 Protocols - OAuth 2.0 Authorization Code Flow".Microsoft Docs.Archivedfrom the original on 29 June 2020.Retrieved29 June2020.
  26. ^"An Introduction to OAuth2 Authentication".Linode.com.22 October 2021.Retrieved18 April2024.
  27. ^"End User Authentication with OAuth 2.0".oauth.net.Archivedfrom the original on 19 November 2015.Retrieved8 March2016.
  28. ^abHammer, Eran (28 July 2012)."OAuth 2.0 and the Road to Hell".Hueniverse.Archived fromthe originalon 25 March 2013.Retrieved17 January2018.
  29. ^Harris, David (October 2021)."Pegasus Mail and Mercury Developer News Archives".Pegasus Mail.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=OAuth&oldid=1253428790"