A Comprehensive Formal Security Analysis of OAuth 2.0

A Comprehensive Formal Security Analysis of OAuth 2.0 arxiv:1601.01229v2 [cs.cr] 7 Jan 2016 Daniel Fett University of Trier, Germany fett@uni-trier.de Guido Schmitz University of Trier, Germany schmitzg@uni-trier.de Ralf Küsters University of Trier, Germany kuesters@uni-trier.de The OAuth 2.0 protocol allows users to grant relying parties access to resources at identity providers. In addition to being used for this kind of authorization, OAuth is also often employed for authentication in single sign-on (SSO) systems. OAuth 2.0 is, in fact, one of the most widely used protocols in the web for these purposes, with companies such as Google, Facebook, or PayPal acting as identity providers and millions of websites connecting to these services as relying parties. OAuth 2.0 is at the heart of Facebook Login and many other implementations, and also serves as the foundation for the upcoming SSO system OpenID Connect. Despite the popularity of OAuth, so far analysis efforts were mostly targeted at finding bugs in specific implementations and were based on formal models which abstract from many web features or did not provide a formal treatment at all. In this paper, we carry out the first extensive formal analysis of the OAuth 2.0 standard in an expressive web model. Our analysis aims at establishing strong authorization and authentication guarantees, for which we provide formal definitions. In our formal analysis, all four OAuth grant types (authorization code grant, implicit grant, resource owner password credentials grant, and the client credentials grant) are covered. They may even run simultaneously in the same and different relying parties and identity providers, where malicious relying parties and identity providers are considered as well. While proving security, we found two previously unknown attacks on OAuth, which both break authorization and authentication in OAuth. The underlying vulnerabilities are present also in the new OpenID Connect standard and can be exploited in practice. We propose fixes for the identified vulnerabilities, and then, for the first time, actually prove the security of OAuth in an expressive web model. In particular, we show that the fixed version of OAuth provides the authorization and authentication properties we specify. 1

Contents 1 Introduction 4 2 OAuth 2.0 6 2.1 Preliminaries........................................ 6 2.2 OAuth Modes........................................ 7 3 Attacks on OAuth 2.0 and OpenID Connect 12 3.1 Attack: 307 Redirect.................................... 12 3.2 Attack: IdP Mix-Up..................................... 13 3.3 Implications to OpenID Connect.............................. 17 3.4 Verification......................................... 18 4 Generic Web Model 18 4.1 Communication Model................................... 18 4.2 Web System......................................... 19 4.3 Web Browsers........................................ 20 5 Analysis of OAuth 2.0 21 5.1 Model of OAuth 2.0..................................... 22 5.2 Authorization and Authentication Properties........................ 24 5.3 Main Theorem........................................ 24 6 Related Work 25 7 Conclusion 26 References 26 A OpenID Connect and the Attacks on this Standard 28 A.1 Modes and Protocol Flow.................................. 30 A.2 The 307 Redirect Attack.................................. 31 A.3 The IdP Mix-Up Attack................................... 31 B The Generic Web Model 33 B.1 Communication Model................................... 33 B.2 Scripting Processes..................................... 37 B.3 Web System......................................... 37 C Message and Data Formats 38 C.1 Notations.......................................... 38 C.2 URLs............................................ 39 C.3 Origins........................................... 39 C.4 Cookies........................................... 39 C.5 HTTP Messages....................................... 39 C.6 DNS Messages....................................... 41 C.7 DNS Servers........................................ 41 D Detailed Description of the Browser Model 41 2

D.1 Notation and Terminology (Web Browser State)...................... 41 D.2 Description of the Web Browser Atomic Process...................... 44 E Formal Model of OAuth 51 E.1 Outline........................................... 52 E.2 Addresses and Domain Names............................... 52 E.3 Keys and Secrets...................................... 52 E.4 Identities, Passwords, and Protected Resources...................... 53 E.5 Corruption.......................................... 54 E.6 Processes in W (Overview)................................. 54 E.7 Network Attackers..................................... 54 E.8 Browsers.......................................... 54 E.9 Relying Parties....................................... 55 E.10 Identity Providers...................................... 62 F Formal Security Properties 66 G Proof of Theorem 1 66 G.1 Properties of OWS...................................... 66 G.2 Proof of Authentication................................... 69 G.3 Proof of Authorization................................... 74 3

1. Introduction The OAuth 2.0 authorization framework [13] defines a web-based protocol that allows a user to grant web sites access to her resources (data or services) at other web sites (authorization). The former web sites are called relying parties (RP) and the latter are called identity providers (IdP). 1 In practice, OAuth 2.0 is often used for authentication as well. That is, a user can log in at an RP using her identity managed by an IdP (single sign-on, SSO). Authorization and SSO solutions have found widespread adoption in the web over the last years, with OAuth 2.0 being one of the most popular frameworks. OAuth 2.0, in the following often simply called OAuth, 2 is used by identity providers such as Facebook, Google, Microsoft, Yahoo, GitHub, and Dropbox. This enables billions of users to log in at millions of RPs or share their data with these [27], making OAuth one of the most used single sign-on systems on the web. OAuth is also the foundation for the new single sign-on protocol OpenID Connect, which is already in use and actively supported by PayPal ( Log In with PayPal ), Google, and Microsoft, among others. Considering the broad industry support for OpenID Connect, a widespread adoption of OpenID Connect in the next years seems likely. OpenID Connect builds upon OAuth and provides clearly defined interfaces for user authentication and additional (optional) features, such as dynamic identity provider discovery and relying party registration, signing and encryption of messages, and user logout. OAuth defines a very complex protocol. The interactions between the user and her browser, the RP, and the IdP can be performed in four different flows, or grant types: authorization code grant, implicit grant, resource owner password credentials grant, and the client credentials grant (we refer to these as modes in the following). In addition, in most of these modes, depending on the configuration and prior setup of the RP and the IdP, further options within the different modes are provided. Therefore, analyzing the security of OAuth is a complex task. So far, most analysis efforts were targeted towards finding errors in specific implementations [4,6,18,26,28], rather than the comprehensive analysis of the standard itself: none of the existing analysis efforts of OAuth account for multiple modes of OAuth running simultaneously, which may potentially introduce new security risks. In fact, many existing approaches analyze only the authorization code mode and the implicit mode of OAuth. Also, importantly, there are no analysis efforts that are based on a comprehensive formal web model, which, however, is essential to rule out security risks that arise when running the protocol in the context of common web technologies. Contributions of this Paper. We perform the first extensive formal analysis of the OAuth 2.0 standard for all four modes, which can even run simultaneously within the same and different RPs and IdPs, based on a comprehensive web model which covers large parts of how browsers and servers interact in real-world setups. Our analysis also covers the case of malicious IdPs and RPs. Informal description of OAuth. As a basis for the model, we first provide a detailed description of the protocol flows in all four modes of OAuth. Formal model of OAuth. Our formal analysis of OAuth uses an expressive Dolev-Yao style model of the web infrastructure [8] proposed by Fett, Küsters, and Schmitz. This model has already been used to analyze the security of the BrowserID single sign-on system [8,10] as well as the security and privacy of the SPRESSO single sign-on system [11]. This web model is designed independently of a specific web application and closely mimics published (de-facto) standards and specifications for the web, for instance, the HTTP/1.1 and HTML5 standards and associated (proposed) standards. It is the most comprehensive web model to date. Among others, HTTP(S) requests and responses, including several headers, such 1 Following the OAuth 2.0 terminology, IdPs are called authorization servers and resource servers, RPs are called clients, and users are called resource owners. Here, however, we stick to the more common terms mentioned above. 2 Note that in this document, we consider only OAuth 2.0, which is very different to its predecessor, OAuth 1.0. 4

as cookie, location, strict transport security (STS), and origin headers, are modeled. The model of web browsers captures the concepts of windows, documents, and iframes, including the complex navigation rules, as well as new technologies, such as web storage and cross-document messaging (postmessages). JavaScript is modeled in an abstract way by so-called scripting processes which can be sent around and, among others, can create iframes and initiate XMLHTTPRequests (XHRs). Browsers may be corrupted dynamically by the adversary. Using this generic web model, we build a formal model of OAuth, closely following the OAuth 2.0 standard [13]. Since this standard does not fix all aspects of the protocol, we use the current OAuth 2.0 security recommendations (RFC6819 [19]) and current web best practices (e.g., regarding sesssion handling) to obtain a model of OAuth 2.0 with state-of-the-art security features in place, in order to avoid known implementation attacks. (Note that the security recommendations in RFC6819 cover many of the bugs found in earlier analysis efforts on implementations of OAuth.) As mentioned above, our model includes RPs and IdPs that (simultaneously) support all four modes and can be dynamically corrupted by the adversary. Also, we model all configuration options of OAuth (see Section 2). Formalization of security properties. Based on this model of OAuth, we provide formal definitions of the security properties of OAuth. In particular, we state two separate properties: authorization and authentication. New attacks on OAuth 2.0 and fixes. While trying to prove these properties, we discovered two previously unknown attacks on OAuth, which both break authorization as well as authentication. In the first attack, IdPs inadvertently forward user credentials (i.e., username and password) to the RP or the attacker. In the second attack, a network attacker can impersonate any victim. This severe attack is caused by a logical flaw in the OAuth 2.0 protocol and depends on the presence of malicious IdP. In practice, OAuth setups often allow for selected (and thus hopefully trustworthy) IdPs only. In these setups the attack would not apply. The attack, however, can be exploited in OpenID Connect, which, as mentioned, builds directly on OAuth. We have verified the attacks on an implementation of OAuth and OpenID Connect. We also notified the respective working groups, who confirmed the attacks and adopted the fixes we propose in this paper. We present our attacks on OAuth in Section 3 in detail. In Appendix A we show how the attacks can be exploited in OpenID Connect. We show how both attacks can be fixed by changes that are easy to implement in new and existing deployments of OAuth and OpenID Connect. Formal analysis of OAuth 2.0. We then prove that OAuth satisfies the authorization and authentication properties in a model of OAuth with the fixes in place. This is the first proof which establishes the security of OAuth in a comprehensive and expressive web model. We note that while these results provide strong security guarantees for OAuth they do not directly imply security of OpenID Connect because OpenID Connect adds specific details on top of OAuth. We leave a formal analysis of OpenID Connect to future work. The results obtained here can serve as a good foundation for such an analysis. Structure of this Paper. In Section 2, we provide a detailed description of the OAuth 2.0 protocol. In Section 3 we present the attacks that we found during our analysis. An overview of the generic web model we build upon in our analysis is provided in Section 4, with the formal analysis of OAuth presented in Section 5. Related work is discussed in Section 6. We conclude in Section 7. We show how the attacks can be applied to OpenID Connect in Appendix A. Full details, in particular regarding our modeling of OAuth 2.0 and the proof, can be found in the appendices B G. 5

2. OAuth 2.0 In this section, we provide a detailed description of OAuth. We here describe in detail all four modes of OAuth. OAuth was first intended for authorization, i.e., the users authorize RPs to access user data (called protected resources) at IdPs. For example, a user can use OAuth to authorize services such as IFTTT 3 to access her (private) timeline on Facebook. In this case, IFTTT is the RP and Facebook the IdP. Roughly speaking, in the most common modes, OAuth works as follows. If a user wants to authorize an RP to access some of the user s data at an IdP, the RP redirects the user (the user s browser) to the IdP where the user authenticates and agrees to grant the RP access to some of her user data at the IdP. Then, along with some token (an authorization code or an access token) issued by the IdP, the user is redirected back to the RP. The RP can then use the token as a credential at the IdP to access the user s data at the IdP. OAuth is also commonly used for authentication, although it was not designed with authentication in mind. A user can, for example, use her Facebook account, with Facebook being the IdP, to log in at the social network Pinterest, being the RP. Typically, in order to log in, the user authorizes the RP to access a unique user identifier at the IdP. The RP then retrieves this identifier and considers this user to be logged in. We now first provide some preliminary information regarding OAuth and then present the details of the four modes of OAuth. 2.1. Preliminaries Endpoints. In OAuth, RPs and IdPs have to provide certain URIs to each other. The parties and services these URIs point to are called endpoints; often the URIs themselves are called endpoints. An IdP provides an authorization endpoint at which the user can authenticate to the IdP and authorize an RP to access her user data. The IdP also provides a token endpoint at which the RP can request access tokens. An RP provides one or more redirection endpoints to which the user s browser gets redirected by an IdP after the user authenticated to the IdP. The URIs of the endpoints are not fixed by the standard, but are communicated when RPs register at IdPs, as described below. The OAuth standard [13] and the accompanying security recommendations [19] suggest that all endpoints use HTTPS. We follow this recommendation in our analysis of OAuth. Registration. Before an RP can interact with an IdP, the RP needs to be registered at the IdP. The details of the registration process are out of the scope of the OAuth protocol. In practice, this process is usually a manual task. During the registration process, the IdP assigns to the RP a fixed OAuth client id and client secret. 4 The RP may later use the client secret to authenticate to the IdP. If the RP cannot keep the OAuth client secret confidential, e.g., if the RP is an in-browser app or a native application, the secret can be omitted. Note that the OAuth client id is public information. It is, for example, revealed to users in redirects issued by the RP. Also, an RP registers one or more redirection endpoints at an IdP. As we will see below, in some OAuth modes, the IdP redirects the user s browser to one of these redirect URIs. If more than one redirect URI is registered, the RP must specify which redirect URI is to be used in each run of the OAuth protocol. For simplicity of presentation, we will assume that an RP always specifies its choice, although this can be omitted if there exits only one (fixed) redirect URI. Note that (depending on the 3 IFTTT (If This Then That) is a web service which can be used to automate actions: IFTTT is triggered by user-defined events (e.g., Twitter messages) and carries out user-defined tasks (e.g., posting on the user s Facebook wall). 4 Recall that in the terminology of the OAuth standard the term client stands for RP. 6

implementation of an IdP) an RP may also register a pattern as a redirect URI and then specify the exact redirect URI during the OAuth run. In this case, the IdP checks if the specified redirect URI matches this pattern. During the registration process, the (fixed) endpoints belonging to an IdP are configured at an RP as well. Our analysis presented in Section 5 covers all the above mentioned options: absence and presence of client secrets, specified redirect URIs, and URI patterns. Login Sessions. As mentioned before, in some OAuth modes, an RP redirects the user s browser to an IdP which later redirects the browser back to the RP. In order to prevent cross-site request forgery (CSRF) attacks, the RP typically establishes a session with the browser before the first redirect. The OAuth standard recommends that an RP selects the so-called state parameter and binds this value to the session, e.g., by choosing a fresh nonce and storing the nonce in the session state. When the user later gets redirected back to the RP, the state value must be identical. The intention is that this value should always be unknown to an attacker in order to prevent CSRF attacks. In our analysis, we follow the recommendation of using the state parameter. 5 Further Recommendations and Options. The standard and the recommendations do not specify all implementation details. For example, the precise user interaction with an RP, formatting details of messages, and the authentication of the user to an IdP (e.g., user name and password or some other mechanism) are not covered. In our security analysis of OAuth we follow all OAuth security recommendations as well as common best practices for state-of-the-art web applications in order to avoid known attacks. OAuth allows RPs to specify which scope of the user s data they are requesting access to at an IdP. The scopes themselves are not defined in the standard and are considered an implementation detail of IdPs. Therefore, in our description and analysis of OAuth, we omit the scope parameter and assume that the user always grants full access to her data at the IdP. 2.2. OAuth Modes OAuth can run in the following four major modes (called grant types in the standard): authorization code mode, implicit mode, resource owner password credentials mode, and client credentials mode. While the first two modes are very commonly used and similar to each other, the latter two modes are used less often and are different to the other modes and to each other. We now describe these modes in detail. Contrary to our analysis, for simplicity of presentation, we only consider a specific set of options in the following description. For example, we assume that an RP always provides a redirect URI and shares an OAuth client secret with the IdP. Authorization Code Mode. When the user tries to authorize an RP to access her data at an IdP or to log in at an RP, the RP redirects the user s browser to the IdP. The user authenticates to the IdP, e.g., by providing user name and password, and is redirected back to the RP along with an authorization code generated by the IdP. The RP then contacts the IdP with this authorization code (along with the client id and client secret) and receives an access token. The RP can then use the access token as a credential to access the user s protected resources at the IdP. Step-by-Step Protocol Flow. In what follows, we describe the protocol flow of the authorization code mode step-by-step (see also Figure 1). First, the user starts the OAuth flow, e.g., by clicking on a 5 Note that the OAuth standard [13] as well as the accompanying security recommendations [19] do not specify the session mechanism for RPs. In our analysis we assume the usual session mechanism with session cookies following common best practices. For more details, see Section 5.1. 7

Browser RP IdP 1 POST /start idp 2 Response Redirect to IdP /authep with client_id, redirect_uri, state 3 GET /authep client_id, redirect_uri, state 4 Response 5 POST /authep username, password 6 Response Redirect to RP redirect_uri with code, state 7 GET redirect_uri code, state 8 POST /tokenep code, client_id, redirect_uri, client_secret 9 Response access_token Authorization: 10 GET /resource access_token 11 Response protected resource Authentication: 12 GET /inspectionep access_token 13 Response user_id, client_id 14 Response session_cookie /Browser /RP /IdP Figure 1. OAuth 2.0 authorization code mode. Note that data depicted below the arrows is either transferred in URL parameters, HTTP headers, or POST bodies. For details see [13]. 8

button to select an IdP, resulting in request 1 being sent to the RP. The RP selects one of its redirect URIs redirect_uri (which will be used later in 7 ) and a value state (as described above). The RP then redirects the browser to the authorization endpoint at the IdP in 2 and 3 with its client_id, redirect_uri, and state appended as parameters to the URI. 6 The IdP then prompts the user to provide her username and password in 4. The user s browser sends this information to the IdP in 5. If the user s credentials are correct, the IdP creates a nonce code (the authorization code) and redirects the user s browser to RP s redirection endpoint redirect_uri in 6 and 7 with code and state appended as parameters to the redirection URI. Next, the RP contacts the IdP in 8 and provides code, client_id, client_secret, and redirect_uri. Then the IdP checks whether this information is correct, i.e., it checks that code was issued for the RP identified by client_id, that client_secret is the correct secret for client_id, that redirect_uri coincides with the one in Step 2, and that code has not been redeemed before. If these checks are successful, the IdP issues an access token access_token in 9. Now, the RP can use access_token to access the user s protected resources at the IdP (authorization) or log in the user (authentication), as described next. When OAuth is used for authorization, the RP uses the access token to view or manipulate the protected resource at the IdP (illustrated in Steps 10 and 11 ). For authentication, the RP fetches a user id (which uniquely identifies the user at the IdP) using the access token as illustrated in Steps 12 and 13. Along with the user id, the RP also receives its OAuth client id from the IdP. The RP checks if this client id is in fact the client id of the RP at the IdP. The RP then issues a session cookie to the user s browser as shown in 14. We note that the IdP may also issue a so-called refresh token along with the access token in Step 9. The RP may use the refresh token along with its credentials to obtain a fresh access token. The refresh token can be considered as a long-living access token, while the access token itself is only valid for a limited time. 7 For brevity of presentation, in the remaining modes, explained below, we only consider authorization. The last steps for both authorization and authentication are analogous to those presented here. Implicit Mode. This mode is a simplified version of the authorization code mode: instead of providing an authorization code to an RP, an IdP directly delivers an access token to the RP (via the user s browser). Step-by-Step Protocol Flow. We now provide a step-by-step description of the protocol flow (see also Figure 2). As in the authorization code mode, the user starts the OAuth flow, e.g., by clicking on a button to select an IdP, triggering the browser to send request 1 to the RP. The RP selects the redirect URI redirect_uri (which will be used later in 7 ) and a value state. The RP then redirects the browser with its client_id, redirect_uri, and state to the authorization endpoint at the IdP 8 in 2 and 3. The IdP prompts the user to enter her username and password in 4. The user s browser sends this information to the IdP in 5. If the user s credentials are correct, the IdP creates an access token access_token and redirects the user s browser to the RP s redirection endpoint redirect_uri in 6 and 7, where the IdP appends access_token and state to the fragment of the redirection URI. (Recall that a fragment is a special part of a URI indicated by the # symbol. When the browser opens a URI, the information in the fragment is not transferred to the server.) Hence, in Step 7 access_token and state are not transferred to the RP. To retrieve these values, the RP in 8 delivers a document containing JavaScript code. It retrieves access_token and state from the fragment and sends these to the RP in 9. The RP then checks if state 6 Note that also a fixed string code indicating to the IdP that authorization code mode is used is appended as a parameter to the URI. 7 In our analysis, we do not explicitly consider refresh tokens. Instead we overapproximate access tokens in that they do not expire, and hence, we make these tokens long-living themselves. Note that refresh tokens are less powerful than such access tokens in the sense that refresh tokens are only useful in combination with the credentials of the appropriate RP. 8 Note that also a fixed string token indicating to the IdP that implicit mode is used is appended as a parameter to the URI. 9

Browser RP IdP 1 POST /start idp 2 Response Redirect to IdP /authep with client_id, redirect_uri, state 3 GET /authep client_id, redirect_uri, state 4 Response 5 POST /authep username, password 6 Response Redirect to RP redirect_uri, fragment: access_token, state 7 GET redirect_uri 8 Response 9 POST /token access_token, state 10 GET /resource access_token 11 Response protected resource /Browser /RP /IdP Figure 2. OAuth 2.0 implicit mode 10

Browser RP IdP 1 POST /start idp, username, password 2 POST tokenep username, password, client_id, client_secret 3 Response access_token 4 GET /resource access_token 5 Response protected resource /Browser /RP /IdP Figure 3. OAuth 2.0 resource owner password credentials mode is the same as above. Just as in the authorization code mode, the RP can now use access_token for authorization (illustrated in Steps 10 and 11 ); authentication is analogous to Steps 12, 13, and 14 of Figure 1. For authentication, note that the response from the IdP includes the RP s OAuth client id, which is also checked by the RP. This check prevents re-usage of access tokens across RPs in the OAuth implicit mode as explained in [29]. We note that in the implicit mode, an IdP cannot verify the identity of the receiver of the access token, as an RP does not authenticate itself to the IdP (using client_secret). Hence, this mode is more suitable for RPs that do not have access to a secure, long-lived storage (for a client_secret) such as in-browser applications. Resource Owner Password Credentials Mode. In this mode, the user gives her credentials for an IdP directly to an RP. The RP can then authenticate to the IdP on the user s behalf and retrieve an access token. The resource owner password credentials mode is intended for highly-trusted RPs, such as the operating system of the user s device or highly-privileged applications, or if the previous two modes are not possible to perform (e.g., for applications without a web browser). In the following, we assume that the authorization/login process is started by the user using a web browser. Step-by-Step Protocol Flow. We now provide a step-by-step description of the resource owner password credentials mode (see also Figure 3): The user provides her username and password for the IdP to the RP in 1. Now, the RP sends the username, the password, its client_id and client_secret 9 to the IdP in 2. The IdP then issues an access token access_token to the RP in 3. 10 Just as in the authorization code mode, the RP can now use access_token for authorization (illustrated in Steps 4 and 5 ) and authentication (as in Steps 12, 13, and 14 of Figure 1). Client Credentials Mode. In contrast to the modes shown above, this mode works without the user s interaction. Instead, it is started by an RP in order to fetch an access token to access RP s own resources 9 Note that in this mode, if an RP does not have an OAuth client secret for an IdP, the client_secret and client_id parameters are both omitted in this request. This option is also covered by our analysis. 10 As in the authorization code mode, an IdP may also issue a refresh token to the RP here. 11

Browser RP IdP 1 POST /tokenep client_id, client_secret 2 Response access_token 3 GET /resource access_token 4 Response protected resource /Browser /RP /IdP Figure 4. OAuth 2.0 client credentials mode at an IdP or to access resources at an IdP the RP is authorized to by other means. For example, Facebook allows RPs to use the client credentials mode to obtain an access token to access reports of their advertisements performance. Step-by-Step Protocol Flow. The step-by-step description of the client credentials mode is as follows (see also Figure 4): First, the RP contacts the IdP with RP s client_id and client_secret in 1. The IdP now issues an access_token in 2. Just as in the authorization code mode, the RP can now use access_token for authorization (illustrated in Steps 3 and 4 ). In contrast to the other modes presented above, the access token is not bound to a specific user account, but only to the RP. 3. Attacks on OAuth 2.0 and OpenID Connect As mentioned in the introduction, while trying to prove the security of OAuth, we discovered two previously unknown attacks, which both apply to the authorization code mode as well as the implicit mode. We call these attacks 307 redirect attack and IdP mix-up attack, respectively. In this section, we provide detailed descriptions of these attacks along with fixes which are easy to implement. Our formal analysis of OAuth (see Section 5) then shows that these fixes are indeed sufficient to establish the security of OAuth. As mentioned in the introduction, the attacks on OAuth also apply to OpenID Connect. Since in this paper the main focus is on OAuth, we only briefly present OpenID Connect and the attacks on this protocol in Section 3.3 and Appendix A. Figure 5 provides an overview of where the attacks apply. We have verified our attacks on an implementation of OAuth and OpenID Connect and reported both attacks to the respective working groups, who confirmed the attacks and adopted our fixes. 3.1. Attack: 307 Redirect In this attack, the attacker (running a malicious RP) learns the user s credentials when the user logs in at an IdP that uses the wrong HTTP redirection status code. Assumptions. We assume that (1) the user wants to log in at a malicious RP (or authorize a malicious RP to access protected resources). Besides providing some (harmless) services, this RP collects all data it receives. We further assume that (2) the IdP that is used for the login chooses the wrong HTTP status code (307) when redirecting the user s browser in Step 6 of the authorization code mode (Figure 1) 12

307 Redirect Attack IdP Mix-Up Attack OAuth OpenID Connect auth. code implicit auth. code implicit hybrid mode mode mode mode mode authorization broken yes yes yes yes yes authentication broken yes yes yes yes yes authorization broken yes* yes yes* yes** authentication broken yes yes yes yes** Figure 5. Attacks on OAuth 2.0 and OpenID Connect: Overview. The attacks are not applicable to resource owner password credentials mode or client credentials mode. (*): if OAuth client credentials are not used. (**): if OAuth client secrets are not used, and otherwise, if such credential are used, then either authorization or authentication is broken, depending on implementation details, see Appendix A. or in Step 6 of the implicit mode (Figure 2). Finally, we assume that (3) the IdP redirects the user immediately after the user entered her credentials (i.e., in the response to the HTTP POST request that contains the form data sent by the user s browser). Assumption (1). This assumption is obviously reasonable. It cannot be assumed that all RPs where some users log in behave honestly. Assumption (2). This assumption is reasonable because neither the OAuth standard [13] nor the OAuth security considerations [19] (nor the OpenID Connect standard [23]) specify the exact method of how to redirect. The OAuth standard rather explicitly permits any HTTP redirect: While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail. Assumption (3). This assumption is reasonable as many examples for redirects immediately after entering the user credentials can be found in practice, for example atgithub.com. (GitHub is not vulnerable to the attack presented here, as assumption (2) is not satisfied in this case.) Attack. When the user uses OAuth (or OpenID Connect, see Section 3.3) to log in at this RP, the user is redirected to the IdP and prompted to enter her credentials. The IdP then receives these credentials from the user s browser in a POST request. It checks the credentials and redirects the user s browser to the RP s redirection endpoint in the response to the POST request. Since the 307 status code is used for this redirection, the user s browser will send a POST request to RP that contains all form data from the previous request, including the user credentials. Since the RP is run by the attacker, it can use these credentials to impersonate the user. Fix. Contrary to the current wording in the OAuth standard, the exact method of the redirect is not an implementation detail but essential for the security of OAuth. In the HTTP standard [12], only the 303 redirect is defined unambigiously to drop the body of an HTTP POST request. All other HTTP redirection status codes, including the most commonly used 302, leave the browser the option to preserve the POST request and the form data. In practice, browsers typically rewrite to a GET request, thereby dropping the form data, except for 307 redirects. Therefore, the OAuth standard should require 303 redirects for the steps mentioned above in order to fix this problem. 3.2. Attack: IdP Mix-Up In this attack, the attacker confuses an RP about which IdP the user chose at the beginning of the login/authorization process in order to acquire an authentication code or access token which can be used 13

Browser RP Attacker (AIdP) HIdP 1 POST /start idp 2 POST /start attacker 3 Response Redirect to Attacker /authep with client_id, redirect_uri, state 4 Response Redirect to HIdP /authep with client_id, redirect_uri, state 5 GET /authep client_id, redirect_uri, state 6 Response 7 POST /authep username, password 8 Response Redirect to RP redirect_uri, fragment: access_token, state 9 GET redirect_uri 10 Response 11 POST /token access_token, state 12 GET /resource access_token Continued attack to break authentication: 13 POST /start idp 14 Response Redirect to HIdP /authep with client_id, redirect_uri, state 15 POST /token access_token, state 16 GET /inspectionep access_token 17 Response user_id, client_id 18 Response session_cookie /Browser /RP /Attacker (AIdP) /HIdP Figure 6. Attack on OAuth 2.0 implicit mode 14

to impersonate the user or access user data. Just as the previous attack, the IdP mix-up attack applies to the authorization code mode and the implicit mode of OAuth. To launch the attack, the attacker manipulates the first request of the user such that the RP thinks that the user wants to use an identity managed by an IdP of the attacker while the user instead wishes to use her identity managed by an honest IdP. As a result, the RP sends the authorization code or the access token (depending on the OAuth mode) issued by the honest IdP to the attacker, who then can use these values to login at the RP under the user s identity (managed by the honest IdP) or access the user s protected resources at the honest IdP. In what follows, we refer to the IdP run by the attacker by AIdP and the honest IdP by HIdP. We present the attack in the implicit mode. The attack for the authorization code mode is very similar and is presented briefly at the end of this section. Assumptions. For the IdP mix-up attack to work, we need two assumptions (see below for further discussion and explanation): (1) the presence of a network attacker who can manipulate the request in which the user sends her identity to the RP as well as the corresponding response to this request (see Steps 1 and 2 in Figure 2), 11 and (2) an RP which allows users to log in with identities provided by (some) HIdP and identities provided by AIdP. We emphasize that we do not assume that the user sends any secret (such as passwords) over an unencrypted channel. Assumption (1). It would be unrealistic to assume that a network attacker can never manipulate Steps 1 and 2 in Figure 2. First, many RPs might not require this request to be HTTPS since no sensitive user data is transferred at this point of the protocol, and hence, an RP might not see the need for encrypted communication for this request. Note that the user only selects an IdP at this point; credentials are not sent. Moreover, the use of HTTPS for this step is not suggested by the OAuth security recommendations. Second, even if an RP intends to use HTTPS also for the first request (as in our model), the attacker can intercept the initial (often unencrypted) request from the user to the RP and alter all links from HTTPS to HTTP and remove any redirections to HTTPS URLs (a technique known as SSL stripping). This interception would fail only if the user accesses the website of the RP using HTTPS from the very beginning (e.g., by entering the URL manually), if RP has set a Strict Transport Security (STS) header in an earlier communication with the browser and this is not circumvented by the attacker (see [25]), or if the RP domain would be included in a browser preloaded STS list [7]. It is, however, unrealistic to assume that all RPs are always protected in one of these ways. We emphasize that our formal analysis presented in Section 5 shows that OAuth can be operated securely even if no HTTPS is used for the initial request (given that our fix, presented below, is applied). We also note that when intercepting the response in Step 2 as discussed here, the attacker could also read the session identifier for the session that the user s browser has established with the RP. Our attack, however, is not based on this possibility and works even if the RP later (at a point where the protocol is protected by HTTPS) changes this session identifier as soon as the user is logged in (a best practice for session management). Assumption (2). This assumption also conforms with the OAuth standard as RPs may use different IdPs. And hence, OAuth should provide security in this case. From the point of view of how OAuth is typically deployed in practice, this assumption might seem unrealistic at first: OAuth RP deployments typically consider only one or two selected (and hopefully trusted) IdPs. OAuth forms, however, the basis for OpenID Connect. There, using the dynamic client registration extension, RPs can dynamically establish an OAuth registration with any IdP. This enables the ad-hoc use of any IdP in OpenID Connect, 11 Note that to manipulate these two messages the network attacker needs to only be able to intercept the communication between the user and the RP (e.g., using ARP spoofing in a wifi network). Importantly, he does not need to intercept messages exchanged between servers. 15

including malicious IdPs. See Section 3.3 and Appendix A for details on how the IdP mix-up attack can be carried out on OpenID Connect in practice. Attack. We now describe the attack on the OAuth implicit mode in detail. As mentioned, a very similar attack also applies to the OAuth authorization code mode and both attacks even work if IdP supports just one of these two modes, rather than both or all four OAuth modes. Note that these two modes are the most common modes in practice. Attack on Implicit Mode. The IdP mix-up attack for the implicit mode is depicted in Figure 6. Just as in the implicit mode, the attack starts when the user selects that she wants to log in using HIdP (Step 1 in Figure 6). Now, the attacker intercepts the request intended for the RP and modifies the content of this request by replacing HIdP by AIdP. The response of the RP 3 (containing a redirect to AIdP) is then again intercepted and modified by the attacker such that it redirects the user to HIdP 4. The attacker also replaces the OAuth client id of the RP at AIdP with the client id of the RP at HIdP. 12 (Note that we assume that from this point on, in accordance with the OAuth security recommendations, the communication between the user s browser and HIdP and the RP is encrypted by using HTTPS, and thus, cannot be inspected or altered by the attacker.) The user then authenticates to HIdP and is redirected back to the RP 8. The RP, however, still assumes that the access token contained in this redirect is an access token issued by AIdP, rather than HIdP. The RP therefore now uses this access token to retrieve protected resources of the user (or the user id) at AIdP 12, rather than HIdP. This leaks the access token to the attacker who can now access protected resources of the user at IdP. This breaks the authorization property (see Section 5.2 below). (We note that at this point, the attacker might even provide false information about the user or her protected resources to the RP.) To break authentication and impersonate the honest user, the attacker now starts a new login process (using his own browser) at the RP. In 13 he selects HIdP as the IdP for this login process. He receives a redirect to HIdP, which he skips. 13 The attacker now sends the access token access_token captured in Step 12 to the RP imitating a real login 15. The RP now uses this access token to retrieve the user id at HIdP 16 and receives the (honest) user s id as well as its own OAuth client id 17. Being convinced that the attacker owns the honest user s account, the RP issues a session cookie for this account to the attacker 18. As a result, the attacker is logged in at the RP under the honest user s id. This breaks the authentication property of OAuth (see Section 5.2 below). Attack on Authorization Code Mode. A similar attack can be applied to the authorization code mode of OAuth. This attack is based on the same assumptions as the attack on the implicit mode. First, the attacker applies the same modifications to the request from the browser to the RP and its response to initiate an OAuth flow. Recall that in the authorization code mode, RP receives an authorization code instead of an access token. The RP then sends this authorization code to the token endpoint of AIdP (in order to request an access token). If the RP does not have a client secret registered at HIdP, the attacker can redeem this authorization code at HIdP in order to receive an access token to access the honest user s protected resources at HIdP. In this case, the authorization property of OAuth (see Section 5.2 below) is broken. Alternatively, the attacker can break the authentication property for OAuth as follows: The attacker starts a new OAuth flow with the RP using his own browser and selecting HIdP as the IdP. He then receives a redirect from the RP to HIdP to authenticate himself. He omits the interaction with HIdP and sends a request to the RP s redirection endpoint containing the authorization code. As this authorization code has not been redeemed before at HIdP, the code is still valid. Hence, when the RP requests an access token with this authorization code at HIdP, HIdP issues such an access token to the RP. The RP 12 As mentioned above, OAuth client ids are public information. 13 Note that this redirect contains (besides a cookie for a new login session) a fresh state parameter, say state. The attacker will use this information in subsequent requests to the RP. 16

retrieves user information with this access token at HIdP, receives the user identifier for the user under attack and considers the attacker to be logged in as this user. (Note that the attacker does not learn an access token in this case.) Fix. A fundamental problem in the implicit mode of the OAuth standard (and similarly for the authorization code mode) is that the redirect in Steps 6 and 7 in Figure 2 does not contain information from where the redirect was initiated. And hence, the RP cannot check whether the information contained in the redirect stems from the IdP that was indicated in Step 1. Our fix therefore is to include the identity of the IdP in the redirect in some form. More specifically, we propose that RPs provide a unique redirection endpoint for each IdP. Hence, the information which IdP redirected the browser to the RP is encoded in the request and the RP can detect a mismatch. Note that the communication at this point in the protocol is secured with HTTPS (when following the OAuth security recommendations) and cannot be manipulated by the attacker. We show in Section 5 that this fix is indeed sufficient. In addition, one could try to prevent the IdP mix-up directly at the beginning of the protocol. (Nonetheless, in any case the RP should be able to check consistency in Step 7.) We have not considered such additional countermeasures because, as we show, our fix is sufficient for the security of OAuth (as far as authorization and authentication goes). 3.3. Implications to OpenID Connect Both, the 307 redirect attack and the IdP mix-up attack, can be applied to OpenID Connect as well. OpenID Connect [23] is a standard for authentication built on top of the OAuth protocol. It was published only recently. Among others, OpenID Connect is already used in practice by PayPal, Google, and Microsoft. OpenID Connect uses the same concept for authentication as described above and supports retrieval of a unique user identifier and further meta data. We here give a brief overview of OpenID Connect and how the attacks apply to this protocol. A detailed description can be found in Appendix A. OpenID Connect defines an authorization code mode, an implicit mode, and a hybrid mode. The former two are based on the corresponding OAuth modes and the latter is a combination of the two modes. OpenID Connect consists of a core protocol and (optional) extensions, such as discovery [24] and dynamic client registration [22]. Both extensions are used to fully automate the registration process between the relying party and the identity provider. This means that, using these extensions, any RP can register dynamically at any IdP. This is triggered, for example, when a user wishes to authenticate with an IdP that the RP is not registered at. In addition to an access token, OpenID Connect uses a so-called id token. The id token is issued by the IdP along with the access token and contains a unique user identifier and additional meta data, such as the intended receiver (the RP) of the id token and the issuer of the id token (the IdP). The id token is (optionally) signed by the IdP. 307 Redirect Attack in OpenID Connect. This attack applies to OpenID Connect in exactly the same way as described above. The vulnerable steps are identical in OAuth and OpenID Connect. IdP Mix-Up Attack in OpenID Connect. In OpenID Connect, the mix-up attack applies to the authorization code mode and the hybrid mode. In the authorization code mode, the attack is very similar to the attack on the OAuth authorization code mode. In the hybrid mode, the attack is more complicated as additional security measures have to be circumvented by the attacker. In particular, it must be ensured that the RP does not detect that the issuer of the id token is not the honest IdP. Interestingly, in the hybrid mode, depending on an implementation detail of the RP, either authorization or authentication is broken (or both if no client secret is used). 17

For details on OpenID Connect and how the attacks can be executed in OpenID Connect see Appendix A. 3.4. Verification We have verified both attacks on mod_auth_openidc, an implementation of an OpenID Connect (and therefore also OAuth) RP. We notified the developers of mod_auth_openidc and reported both attacks to the OAuth and OpenID Connect working groups, who confirmed that changes to the standard (and recommendations) are needed to mitigate the attacks. 4. Generic Web Model Our formal security analysis of OAuth is based on the general Dolev-Yao style web model proposed by Fett et al. in [8], with extensions presented in [11]. This web model is designed independently of a specific web application and closely mimics published (de-facto) standards and specifications for the web. Based on a general communication model, the model specifies web systems, which contain browsers, DNS servers, and web servers as well as web and network attackers. Here, we only briefly recall this model (see the mentioned papers for a full description). 4.1. Communication Model The main entities in the communication model are atomic processes, which are used to model web browsers, web servers, DNS servers as well as web and network attackers. Each atomic process listens to one or more (IP) addresses. A set of atomic processes forms what is called a system. Atomic processes can communicate via events, which consist of a message as well as a receiver and a sender address. In every step of a run, one event is chosen non-deterministically from the current pool of events and is delivered to one of the atomic processes that listens to the receiver address of that event. The atomic process can then process the event and output new events, which are added to the pool of events, and so on. More specifically, messages, processes, etc. are defined as follows. Terms, Messages and Events. As usual in Dolev-Yao models (see, e.g., [1]), messages are expressed as formal terms over a signature. The signature Σ for the terms and messages considered in the web model contains, among others, constants (such as (IP) addresses, ASCII strings, and nonces), sequence and projection symbols, and further function symbols, including those for (a)symmetric encryption/decryption and digital signatures. Messages are defined to be ground terms (terms without variables). For example, pub(k) denotes the public key which belongs to the private key k. To provide another example of a message, in the web model, an HTTP request is represented as a ground term containing a nonce, a method (e.g., GET or POST), a domain name, a path, URL parameters, request headers (such as Cookie), and a message body. For instance, an HTTP GET request for the URL http://ex.com/show?p=1 is modeled as the term r := HTTPReq,n 1,GET,ex.com,/show, p,1,,, where headers and body are empty. An HTTPS request for r is of the form enc a ( r,k,pub(k ex.com )), where k is a fresh symmetric key (a nonce) generated by the sender of the request (typically a browser); the responder is supposed to use this key to encrypt the response. Events are terms of the form a, f,m where a and f are receiver/sender (IP) addresses, and m is a message, for example, an HTTP(S) message as above or a DNS request/response. 18

The equational theory associated with the signature Σ is defined as usual in Dolev-Yao models. The theory induces a congruence relation on terms. It captures the meaning of the function symbols in Σ. For instance, the equation in the equational theory which captures asymmetric decryption is dec a (enc a (x,pub(y)),y)=x. With this, we have that, for example, dec a (enc a ( r,k,pub(k ex.com )),k ex.com ) r,k, i.e., these two terms are equivalent w.r.t. the equational theory. Atomic Processes, Systems and Runs. Atomic Dolev-Yao processes, systems, and runs of systems are defined as follows. An atomic Dolev-Yao (DY) process is a tuple p=(i p,z p,r p,s p 0 ) where I p is the set of addresses the process listens to, Z p is a set of states (formally, terms), s p 0 Z p is an initial state, and R p is a relation that takes an event and a state as input and (non-deterministically) returns a new state and a sequence of events. This relation models a computation step of the process, which upon receiving an event in a given state non-deterministically moves to a new state and outputs a set of events. It is required that the events and states in the output can be computed (more formally, derived in the usual Dolev-Yao style) from the current input event and state. An atomic process may also create fresh nonces in a computation step. The so-called attacker process is an atomic DY process which records all messages it receives and outputs all events it can possibly derive from its recorded messages. Hence, an attacker process is the maximally powerful DY process. It carries out all attacks any DY process could possibly perform and is parametrized by the set of sender addresses it may use. Attackers may corrupt other DY processes (e.g., a browser). A system is a set of atomic processes. A configuration (S, E, N) of this system consists of the current states of all atomic processes in the system (S), the pool of waiting events (E), and the mentioned sequence of unused nonces (N). A run of a system for an initial sequence of events E 0 is a sequence of configurations, where each configuration (except for the initial one) is obtained by delivering one of the waiting events of the preceding configuration to an atomic process p (which listens to the receiver address of the event), which in turn performs a computation step according to its relation R p. The initial configuration consists of the initial states of the atomic processes, the sequence E 0, and an initial infinite sequence of unused nonces. Scripting Processes. The web model also defines scripting processes, which model client-side scripting technologies, such as JavaScript. A scripting process (or simply, a script) is defined similarly to a DY process. It is called by the browser in which it runs. The browser provides it with state information s, and the script then, according to its computation relation, outputs a term s, which represents the new internal state and some command which is interpreted by the browser (see also below). Again, it is required that a script s output is derivable from its input. Similarly to an attacker process, the so-called attacker script R att may output everything that is derivable from the input. 4.2. Web System A web system formalizes the web infrastructure and web applications. Formally, a web system is a tuple (W,S,script,E 0 ) 19

with the following components: The first component, W, denotes a system (a set of DY processes as defined above) and contains honest processes, web attacker, and network attacker processes. While a web attacker can listen to and send messages from its own addresses only, a network attacker may listen to and spoof all addresses (and therefore is the maximally powerful attacker). Attackers may corrupt other parties. In the analysis of a concrete web system, we typically have one network attacker only and no web attackers (as they are subsumed by the network attacker), or one or more web attackers but then no network attacker. In analysis of OAuth we consider network attackers. Honest processes can either be web browsers, web servers, or DNS servers. The modeling of web servers heavily depends on the specific application. The web browser model, which is independent of a specific web application, is presented below. The second component, S, is a finite set of scripts, including the attacker script R att. In a concrete model, such as our OAuth model, the set S \{R att } describes the set of honest scripts used in the web application under consideration while malicious scripts are modeled by the worst-case malicious script, R att. The third component, script, is an injective mapping from a script in S to its string representation script(s) (a constant in Σ) so that it can be part of a messages, e.g., an HTTP response. Finally, E 0 is a sequence of events, which always contains an infinite number of events of the form a,a,trigger for every IP address a in the web system. A run of the web system is a run of W initiated by E 0. 4.3. Web Browsers We now sketch the model of a web browser. A web browser is modeled as a DY process (I p,z p,r p,s p 0 ). An honest browser is thought to be used by one honest user, who is modeled as part of the browser. User actions are modeled as non-deterministic actions of the web browser. For example, the browser itself non-deterministically follows the links in a web page. User data (i.e., passwords and identities) is stored in the initial state of the browser and is given to a web page when needed, similar to the AutoFill feature in browsers. Besides the user identities and passwords, the state of a web browser (modeled as a term) contains a tree of open windows and documents, lists of cookies, localstorage and sessionstorage data, a DNS server address, and other data. In the browser state, the windows subterm is the most complex one. It contains a window subterm for every open window (of which there may be many at a time), and inside each window, a list of documents, which represent the history of documents that have been opened in that window, with one of these documents being active, i.e., this document is presented to the user and ready for interaction. A document contains a script loaded from a web server and represents one loaded HTML page. A document also contains a list of windows itself, modeling iframes. Scripts may, for example, navigate or create windows, send XHRs and postmessages, submit forms, set/change cookies, localstorage, and sessionstorage data, and create iframes. When activated, the browser provides a script with all data it has access to, such as a (limited) view on other documents and windows, certain cookies as well as localstorage and sessionstorage. Figure 7 shows a brief overview of the browser relation R p which defines how browsers behave. For example, when a TRIGGER message is delivered to the browser, the browser non-deterministically choses an action. If, for instance, this action is 1, then an active document is selected non-deterministically, 20