OAuth 2.0 : Architectural design augmentation for mitigation of common security vulnerabilities

Abstract

OAuth 2.0 is a widely used authorization protocol for cloud based web services and is used by many big firms such as Google, Facebook, Microsoft for granting limited access to the data. OAuth 2.0 has a flexible design and can be implemented and configured in a number of ways according to the use case. However, each of these implementation decisions and configuration choices come with their respective security implications. In our research, we carry out a simulation of the OAuth 2.0 protocol and suggest additional features which can augment the architectural design and enhance overall security effectiveness of the protocol. The protocol classifies third-party client apps based on their ability to maintain the confidentiality of the secret keys and the method used by them to register with the authorization servers. The protocol further offers various options to send access tokens to third-party client apps. In our research, we suggest converging these different third-party client app types and implementation options into a single uniform client app type and operational flow, thereby reducing the complexity in decision making, implementation, security misconfigurations and maintenance of different codebases. We also propose incorporating 2FA (Two Factor Authentication) as a feature for authentication of third-party client apps in addition to the existing mechanism of basic authentication through client secret. We also advocate measures to utilize digital signatures and cryptography to mitigate the common risks and vulnerabilities associated with misuse of tokens, which are issued and exchanged at various stages of the OAuth process including access to protected resources.

Introduction

OAuth 2.0 is one of the most common and widely used authorization frameworks in the industry and has already become a standard. It is specified in RFC 6749: The OAuth 2.0 Authorization Framework [1]. It is widely used by Google, Microsoft (MSN, Live), Facebook, Instagram, GitHub, Meetup, and many other popular technology platforms as also mentioned by Siriwardena et al. [2] and S. Pai et al. [3].

The OAuth framework supports scope restricted access to client-data, without the client requiring to share its credentials with the third-party applications see Leiba et al. [4]. In the first example, a social media app such as LinkedIn may require access to the contact list of a user account registered with Google to suggest people to connect with. In another example a third-party application may want to read the profile information of a users account registered with Google. In both cases, the application i.e Google, holding users’ data wants to delegate the access of limited user data to a third-party application.

One of the naive ways to give access to the protected resources to third-party apps is by sharing the credentials with the these apps which can then directly access the user data. This is called access delegation by sharing the credentials. It seemingly solves the access delegation problem, however, once the third-party application has the credentials, it can misuse them to gain access to user account and data in an uncontrolled and unrestricted manner. OAuth provides a framework where credentials are not shared with any of the third-party applications, but only time-bound tokens are shared which are good enough for temporary access and for a well-defined scope. The OAuth specification allows a person to control the access to protected resource available on one app from another app. So, the users can control exactly what to share with another app. OAuth 2.0 is primarily an authorization protocol and does not deal with how the resource owners authenticate with the applications holding their protected data. Resource owner authentication can be done with any of the existing ways such as password based authentication or more sophisticated solutions like single sign-on, where the resource owner can pass some Security Assertion Markup Language (SAML) that proves his/her identity.

OAuth 2.0 has attracted a lot of interest as it is both commonly used and prone to implementation mistakes as brought out by San-Tsai et al. [5]. Previous studies have revealed that in practice the developers often implement OAuth 2.0 incorrectly, and so a number of real-world OAuth 2.0 systems are vulnerable to attacks see Göçer et al. [6]. There are many optional parameters and configuration settings in an OAuth flow, which leaves plenty of scope for misconfigurations. These misconfigurations result in vulnerabilities that can allow attackers to get hold of sensitive user data and potentially bypass the authorization process completely. The users of such vulnerable systems are typically unaware of the issues, and are at risk of unauthorized access to their protected account information and data as brought out in the study by Wanpeng et al. [7].

In this paper, we simulate the OAuth 2.0 process flow with the help of a use case. This provides us with a necessary background for the study of the protocol design and the implementation process. Thereafter, based on the known vulnerabilities of OAuth process see Yaworski [8], RFC 6819 [9], Richer et al. [10], and our observations during the simulation, we propose augmentation in architectural design which can mitigate the known security vulnerabilities associated with typical OAuth 2.0 processes.

In our research we have suggested use of Two Factor Authentication (2FA) as an additional security layer for authentication of third-party client apps. Two factor authentication is based on the idea of providing two of the following three “somethings”:

• Something you Know. It could be the password or pin for a user account and API key in case of code.

• Something you Have. It could be an authenticator application or a physical hardware token.

• Something you Are. It is a unique fingerprint like biometric identity in case of individuals or hash signatures in case of document or software binaries.

The 2FA will add an additional security overlay and mitigate the risks associated with abuse of leaked client credentials/ client_secret by malicious client apps. The security architecture proposed in this paper will reduce the sole dependence on client_secret for the authentication of the third-party client app by the authorization server for issuing tokens to access protected resources. The leakage of client credentials could result in replay attacks on tokens and impersonation of client application by a malicious application as mentioned in RFC 6819 [9].

OAuth process can be implemented in a number of ways depending upon the type of client app such as web, desktop or mobile and its ability to maintain the confidentiality of the client secret. In this paper we advocate converging different client app types and implementation flows of OAuth processes into a single uniform client app type and process flow. This will reduce the complexity in decision making, implementation, security misconfigurations and maintenance of codebases. The major Identity Providers (IdPs) like Google and Microsoft are already supporting a common flow of OAuth 2.0 for different types of applications on their platforms see Microsoft documentation [11] and Google developer documentation [12].

In this paper we propose utilization of digital signatures and cryptography to mitigate the common risks and vulnerabilities associated with misuse of tokens issued and exchanged at various stages of the OAuth 2.0 flow. There are various vulnerabilities associated with redirect URI which can result in leakages of the tokens see Morkonda et al. [13], Peter Yaworski [8] and Richer et al. [10]

The Section 2 of the paper elucidates the actors and grant types involved in the OAuth flow. The Section 3 describes JavaScript Object Notation (JSON) Web Tokens which are extensively used in the implementation process. Section 4 is about simulation of a typical OAuth 2.0 use case. Section 5 reviews the existing threat model. Section 6 describes the architectural design augmentation and its comparison with existing OAuth 2.0 specifications. In Section 7, we conclude the paper and provide for future scope.