OAuth
OAuth (short for "Open Authorization"[1][2]) 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.[3][4] This mechanism is used by companies such as Amazon,[5] Google, Meta Platforms, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites.
Latest version
Generally, the OAuth protocol provides a way for resource owners to provide a client [application] with 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 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]
Security issues[edit]
OAuth 1.0[edit]
On 23 April 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.[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 new best current practice internet 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 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.[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]
OAuth framework specifies several grant types for different use cases. Some of the most common OAuth grant types are:[22]
Uses[edit]
Facebook's Graph API only supports OAuth 2.0.[23] Google supports OAuth 2.0 as the recommended authorization mechanism for all of its APIs.[24] Microsoft also 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 secured RSS/Atom feeds. Access to 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 accessed using Google Reader. Instead, three-legged OAuth would have been used to authorize that RSS client to access the feed from the Google Site.
Controversy[edit]
Eran Hammer resigned from his role of lead author for the OAuth 2.0 project, withdrew from the IETF 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 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.[2]
David Harris, author of the email client Pegasus 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]