OAuth (Open Au­tho­riza­tion)

Nowadays, we use numerous websites, programs, and mobile apps to make our personal and pro­fes­sion­al lives easier or more com­fort­able. With such a wide variety of tools, it has become normal for many people to use an app such as Instagram on another website such as Facebook. In other words, it is possible to operate across platforms. However, since a lot of personal data is trans­ferred during these processes, it makes sense to question the security of this transfer. The OAuth au­tho­riza­tion protocol is designed to reduce the risk of unau­tho­rized data misuse – our question is, can it do justice to this weighty ask?

OAuth, short for “open au­tho­riza­tion,” is an open standard protocol that enables secure API au­tho­riza­tion. The technical term API (short for “Ap­pli­ca­tion Pro­gram­ming Interface”) refers in this context to an interface that functions as a data trans­mit­ter between different ap­pli­ca­tions, user in­ter­faces, or web pages. Au­tho­riza­tion of such data transfers performed by APIs is necessary because without them there is a risk that unau­tho­rized third parties may intercept the data and misuse it for their own purposes.

This means that if, for example, an app is to post on Facebook in the name of the user (i.e. access the Facebook API), it must have per­mis­sion from this user. Likewise, an ap­pli­ca­tion needs the user's authority to extract their profile in­for­ma­tion from another service. Through OAuth, the user can give this au­tho­riza­tion without having to provide the au­tho­rized ap­pli­ca­tion with their username and password – in other words, they retain full control over their data.

Con­verse­ly, providers such as Google, Twitter, and Facebook can use OAuth to make their products and services more flexible and at the same time more secure, for example by means of single sign-on solutions. Amazon and Microsoft have also joined the ranks of large companies that use OAuth as their access del­e­ga­tion standard for their services.

The OAuth2 (also called “OAuth 2.0”) was published in October 2012 as a complete revision of OAuth and has now largely replaced it. The Graph API of Facebook only supports the new protocol as au­tho­riza­tion standard. It serves the au­then­ti­ca­tion layer OpenID Connect (OIDC) as a basis.

In principle, the task of OAuth2 is the same as that of its pre­de­ces­sor – providing the user with more flex­i­bil­i­ty and high security at the same time by means of API au­tho­riza­tion. However, numerous weak­ness­es of the original protocol were fixed, making coding and im­ple­men­ta­tion more difficult as the systems of Facebook, Twitter, and other API operators became more complex over time.

Apart from a complete change in ter­mi­nol­o­gy, the most important new feature of OAuth2 is that, unlike its pre­de­ces­sor, it no longer requires cryp­to­graph­ic sig­na­tures for any machine-to-machine com­mu­ni­ca­tion. This makes its ap­pli­ca­tion much easier. But it also means that the new protocol is tech­ni­cal­ly less secure – a fact that brought some criticism to OAuth2.

Open Au­tho­riza­tion 2.0 has also been enhanced with more dif­fer­en­ti­at­ed grant types and improved protocol per­for­mance. The de­vel­op­ers have achieved this by OAuth2 no longer asking for the access data of the user (resource owner) at each com­mu­ni­ca­tion step, but only at the initial au­tho­riza­tion of the re­spec­tive ap­pli­ca­tion (client). Another notable in­no­va­tion are access tokens with shorter validity that make it easier for a service (resource server) to revoke au­tho­riza­tions. In addition, the user can decide under OAuth2 which au­tho­riza­tions (scope) they grant to an ap­pli­ca­tion.

Es­pe­cial­ly when it comes to single sign-on (SSO), OAuth is often mentioned in the same breath as OpenID and SAML. Although all these concepts are about the reliable ver­i­fi­ca­tion of user iden­ti­ties, there are big dif­fer­ences between the three.

OpenID (short for “open iden­ti­fi­ca­tion”) is, as the name suggests, an open protocol. When a user creates an OpenID account, they can use it to log on to other services and ap­pli­ca­tions that also support OpenID via a token. A good example of this is the “register with Google” function, which can now be found on many websites, and which allows a single sign-on procedure via the user's Google account.

In contrast to OAuth, OpenID is not strictly speaking an au­tho­riza­tion, but an au­then­ti­ca­tion procedure. The two pro­ce­dures have been closely linked since 2014: OAuth 2.0 is the basis on which the new version of OpenID, called OpenID Connect (OIDC), is built. OAuth2 allows different types of ap­pli­ca­tions (clients) to verify the user's identity through au­then­ti­ca­tion by an au­tho­riza­tion server – and to obtain ad­di­tion­al basic in­for­ma­tion about the user. In return, all the necessary functions for login and single sign-on are added. OpenID Connect can also be extended with optional functions such as session man­age­ment and en­cryp­tion of identity data.

The open and XML-based “Security Assertion Markup Language” (short: SAML) combines the prop­er­ties of the two previous concepts. It is a standard for both au­then­ti­ca­tion and au­tho­riza­tion. SAML is similar in its func­tion­al­i­ty to OpenID and is also used for single sign-on pro­ce­dures.

Taking a look at an overview of the roles and approval processes defined in the OAuth2 protocol will be helpful in un­der­stand­ing how it works.

OAuth2 defines four roles:

• Resource owner (also: user): An entity that grants a client access to its protected data (also: resources).
• Resource server (also: service): A server on which the protected data of the resource owner is stored.
• Client (also: third party): A desktop, web, or mobile ap­pli­ca­tion that wants to access the protected data of the resource owner.
• Au­tho­riza­tion server: A server that au­then­ti­cates the resource owner and issues a temporary access token for a scope defined by the resource owner. In practice, Au­tho­riza­tion Server and Resource Server are often operated together and are then also referred to as OAuth Server.

Fur­ther­more, a dis­tinc­tion is made between four pre­de­fined approval processes (grant types), which are used in various ap­pli­ca­tions:

• Au­tho­riza­tion code: The client asks the resource owner to log in to the au­tho­riza­tion server. The resource owner is then redi­rect­ed to the client along with an au­tho­riza­tion code. In exchange for this code, the au­tho­riza­tion server issues an access token for the client.
• Implicit au­tho­riza­tion: This approval process is very similar to au­tho­riza­tion by au­tho­riza­tion code, but is less complex because the au­tho­riza­tion server issues the access token directly.
• Resource owner password cre­den­tials: Here, the resource owner entrusts his access data directly to the client, which is largely contrary to the basic principle of OAuth, but means less effort for the resource owner.
• Client cre­den­tials: This very simple approval process is used when the client wants to access data that does not have an owner or does not require au­tho­riza­tion.

If the client needs access to the protected data of the resource owner again in the future, it can use a refresh token that is limited in time but has a much longer service life to request a new access token from the au­tho­riza­tion server. No reau­tho­riza­tion by the resource owner is required.

Social networks Pinterest and Facebook provide concrete examples of the OAuth2 procedure. Pinterest offers the option to import contacts from Facebook friend lists. To do this, Pinterest needs access to the re­spec­tive account and the in­for­ma­tion stored there. For data security reasons, however, it is unwise to pass the username and password from Facebook onto Pinterest – after all, Pinterest would then have unlimited access to all data and functions of the Facebook account at any time. In order for Pinterest to still be able to access the required Facebook data, OAuth2 is used:

1. First you log into your Pinterest account and navigate to the settings in the user profile.
2. In the menu bar “social networks” move the slider next to “Facebook” to “yes.”
3. Pinterest now asks you to log in to Facebook and confirm the Pinterest app. This action is con­sid­ered au­tho­riza­tion.
4. Pinterest requests an access token from Facebook’s au­tho­riza­tion server and then uses it to access the protected data on the resource server.
5. The imported Facebook friends are now also displayed in the Pinterest account.

The fact that even a system designed for the pro­tec­tion of personal data such as OAuth cannot be one hundred percent perfect was already demon­strat­ed in April 2009, when a security gap was dis­cov­ered in the au­then­ti­ca­tion process. As with many other such systems, phishing is also a constant risk, and between April and May 2017, one million Gmail users were victims of an OAuth-based phishing attack. In a fraud­u­lent e-mail, users were asked to authorize a fake interface to allow an alleged ap­pli­ca­tion called “Google Apps” access to their account in­for­ma­tion.

In October 2012, the effort of upping security from OAuth in its new model, OAuth 2 reached a final result – but without the approval of the original de­vel­op­ers. Only OAuth2 editor-in-chief Eran Hammer-Lahav had worked on the old OAuth – and even he even­tu­al­ly distanced himself from the new project, three months before its release. In an article on his blog hueni­verse.com from July 26, 2012, he explained the back­ground on his decision and called OAuth 2.0 "way to hell" in the headline.

What happened? According to Hammer-Lahav, the de­vel­op­ment of the new protocol had been de­ter­mined by constant debates between the de­vel­op­ers and the companies involved (including Yahoo!, Google, Twitter, and Deutsche Bank). At some point, issues were ignored in favor of economic interests. The con­se­quence would be a program which, according to Hammer-Lahav, could no longer be described as secure. Instead of rep­re­sent­ing a precise stan­dard­ized protocol, OAuth2 is at most a framework that can be adapted and extended at will.

One more thing Hammer-Lahav regrets is the fact that the decision was made to implement OAuth 2.0 more easily (for example by omitting sig­na­tures), which leads to a lack of security. In order to program a secure ap­pli­ca­tion that supports OAuth2, de­vel­op­ers would need to have a con­sid­er­able amount of expertise. It is therefore more likely that insecure ap­pli­ca­tions will ac­cu­mu­late on the network in the future. Im­ple­men­ta­tion errors are un­avoid­able, given the in­com­plete and ex­ces­sive­ly complex spec­i­fi­ca­tions, says Hammer-Lahav.

Hammer-Lahav was somewhat correct in his concerns. In 2016, a research group at Uni­ver­si­ty of Trier had to deal with the security of OAuth2 and dis­cov­ered two security gaps. One of them allowed man-in-the-middle attacks. Basically, however, the re­searchers con­sid­ered the protocol to be rel­a­tive­ly safe – provided it was im­ple­ment­ed correctly.