There are many attacks that you need to address when implementing an OAuth or OpenID Connect client. Despite its severe impact one attack is often overlooked in the process of securing clients; in a so-called “mix-up attack” an attacker makes use of a malicious authorization server to steal authorization codes or access tokens. Afterwards, the attacker can access the victim’s resources.
In this blog post we explain the best way how you can protect your application and prevent the severe impact of mix-up attacks.
What Are Mix-Up Attacks?
Mix-up attacks might look complex but they are based on a simple idea: An attacker tricks a client into sending an authorization code or an access token to an authorization server (AS) controlled by the attacker instead of the indented honest authorization server or resource server. The client “mixes up” which authorization server it is interacting with.
There are multiple variants of mix-up attacks targeting OAuth or OpenID Connect. Figure 1 shows one example: The victim starts an authorization grant at a legitimate client using the honest authorization server (H-AS). However, the attacker changes the victim’s request to the client and enforces it to use the attacker’s authorization server (A-AS) instead (1). The client stores the A-AS as the selected authorization server of the victim’s session and redirects the victim to the A-AS (2). The attacker exchanges the client ID with the one the client uses at the H-AS and forwards the victim to the H-AS (3). When the client receives the authorization response, it does not recognize that it was issued by the H-AS (5). The client issues the token request to the authorization server that is associated with the victim’s session - the A-AS. Therefore, the client leaks the authorization code to the attacker (6). More details and other mix-up attack variants can be found here.
Figure 1: Example of a mix-up attack variant (some parameters have been removed for display purposes).
The basic idea of mix-up attacks already includes an important prerequisite: A vulnerable OAuth client must support multiple authorization servers and at least one of them must be controlled by an attacker. There are multiple ways an attacker can gain control of an authorization server. For example, the attacker might be able to compromise an already supported authorization server or register the client with their own authorization server using dynamic client registration. [1, Section 4.4.]
This means that mix-up attacks are not applicable to clients which support one authorization server only. However, these clients should not ignore mix-up attacks. We recommend considering implementing countermeasures to your client anyway. The reason for this recommendation is that your client might implement support for a second authorization server in the future. The question arises if you remember to address mix-up attacks at this point. By supporting a second authorization server your client might become vulnerable to mix-up attacks right away.
How Can I Currently Protect My Client?
Mix-up attacks can have severe impacts on the security of clients and OAuth-protected resources. It is important to apply effective countermeasures to protect confidentiality and integrity for legitimate users.
In order to recognize a mix-up attack, the client must be able to determine the issuer of the authorization response (step (5) in Figure 1). This way the client recognizes that the authorization response was not issued by the authorization server the client thinks it interacts with.
In the following we want to briefly discuss two standard-conform countermeasures based on this idea as well as their drawbacks:
1. OpenID Connect Hybrid Flow
If the client and authorization server use OpenID Connect, they can make use of the hybrid flow (response_type=code+id_token) to defend against mix-up attacks: The authorization server issues an ID token and includes it in the authorization response. This ID token contains the issuer’s identity in the iss claim. The client can extract the iss claim (after verifying the signature of the ID token) and use it to determine whether the response was issued by the expected authorization server.
While this countermeasure works fine for OpenID Connect clients, it cannot be used to protect plain OAuth authorization flows. Implementing OpenID Connect as a countermeasure against mix-up attacks is not reasonable. Even when the client uses OpenID Connect, but the code instead of the hybrid flow, it might not be the best solution to switch to the hybrid flow. The client needs to be extended to be able to validate the ID token in the front channel which adds complexity to its code base.
2. Distinct Redirect URIs for Each Issuer
Clients can utilize the redirect URI to determine which authorization server issued an authorization response. This is achieved by using distinct redirect URIs for each issuer: A client uses a unique redirect URI for each authorization server during the registration process. It can then check which redirect URI the authorization response in question was sent to.
While the use of distinct redirect URIs for each issuer might provide some protection against mix-up attacks in some scenarios, there are also flaws with this solution. The attacker can try to make the client use a redirect URI with the A-AS other than the one the client intended. For example, if the client uses dynamic client registration to register at the A-AS, the attacker might be able to influence which redirect URI the client stores in its configuration for the A-AS. This way the attacker can circumvent the countermeasure and still successfully execute mix-up attacks.
What Is the Best Countermeasure Against Mix-Up Attacks?
The currently available standard-conform countermeasures described above both have drawbacks and do not provide a sufficient protection against mix-up attacks. Luckily there is a third possibility that enables every OAuth and OpenID Connect client to determine who issued the authorization response.
The simple idea is to add the issuer identifier of the authorization server directly to the authorization response using a new response parameter. This idea is not new. It actually dates back to when mix-up attacks were first discovered. Despite first efforts [2], the countermeasure was never properly standardized (until now – see Update #2 below) which means authorization servers and clients might interpret and implement the idea in different ways. For example, two authorization servers might use different names for the parameter making it difficult for clients to implement the countermeasure effectively.
A few months back, we and some people of the OAuth working group decided this countermeasure should become a standard. We started to work on an individual draft in the Internet Engineering Task Force (IETF) which specifies exactly how an authorization server could (and should) include its issuer identifier in the authorization response. The result is the “OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response” draft which specifies how to use and validate the iss parameter in the authorization response. [3]
The following example shows an authorization response from the authorization server whose issuer identifier is https://honest.as.example (extra line breaks and indentation are for display purposes only):
HTTP/1.1 302 Found
Location: https://client.example/cb?
code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
&state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
&iss=https%3A%2F%2Fhonest.as.example
The draft outlines two important aspects in the context of the iss parameter: First, it mandates that an authorization server must provide its issuer identifier to clients, for example, by using OAuth metadata. The metadata allows the clients to compare it to the value of the iss parameter. Second, it points out how clients must validate the iss parameter when they receive an authorization response. If the validation is not successful, clients must reject the response and abort the authorization flow. More details can be found in the current draft version -02.
Conclusion and Outlook
Mix-up attacks are a possible threat to OAuth and OpenID Connect clients; they are relevant to all clients which do support multiple authorization servers. Currently standard-compliant countermeasures are either not suitable for all clients or do not provide sufficient protection. Our proposal attempts to solve this problem by specifying the iss parameter. We believe that the current draft is in a very stable state and do not expect major changes in the future. If you develop an authorization server feel free to implement the current version.
We are happy to hear any feedback on the current draft and to further improve it. We hope to convince the OAuth working group to make the draft an official OAuth draft soon. When the final standard is published, the iss parameter could be included as the recommended countermeasure against mix-up attacks in the “OAuth 2.0 Security Best Current Practice” [1] and also a future version 2.1 of OAuth. [4]
Feel free to join the virtual meeting of the OAuth working group on Monday, 07th December (details) where we will discuss the current draft.
Update: Official OAuth Draft
The OAuth working group decided to adopt our draft. This allows us to continue our work within the working group.
The first version (-00) of the official OAuth working group draft is identical to version -02 of our individual draft. You can find the latest version of "draft-ietf-oauth-iss-auth-resp" here.
Update #2: Official Internet Standard – RFC9207
In March 2022 our draft became an official Internet standard published by the IETF [5] – RFC9207.
There are already some implementations supporting RFC9207. This allows you to protect your application with the most effective countermeasure against the severe dangers of mix-up attacks.
If you want to learn more about mix-up and other attacks or the security of OAuth, OpenID Connect, and other Single Sign-On solutions, in general, have a look at our in-depth Single Sign-On training courses.
Do you think the attack described above is interesting and would you like to execute it in a penetration test yourself? Have a look at our career page and see if there is an interesting job offer for you.
[1] T. Lodderstedt et al. OAuth 2.0 Security Best Current Practice - Draft 16. Internet Engineering Task Force, 2020. URL: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16.
[2] M. Jones et al. OAuth 2.0 Mix-Up Mitigation - Draft 01. Internet Engineering Task Force, 2016. URL: https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01.
[3] K. Meyer zu Selhausen, D. Fett. OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response - Draft 02. Internet Engineering Task Force, 2020. URL: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02.
[4] D. Hardt et at. The OAuth 2.1 Authorization Framework - Draft 00. Internet Engineering Task Force, 2020. URL: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00.
[5] K. Meyer zu Selhausen, D. Fett. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification. Internet Engineering Task Force, 2022. URL: https://www.rfc-editor.org/rfc/rfc9207.html
Our Experts Develop the Optimal Solution for You
APIs – OAuth – FAPI
Are you faced with the decision of how to best protect your APIs and customer data? Or are you already using OAuth and wondering if your implementation is secure?
We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure APIs with us. We look forward to supporting you with your projects.
Your Contact for OAuth and secure APIs
Dr. Christian Mainka
christian.mainka@hackmanit.de