# Exploiting Auth0 Misconfigurations: A Case Study on Account Linking Vulnerabilities

During a comprehensive security assessment of an application using Auth0, my colleague Kareem Al Sadeq and I discovered a critical vulnerability that allowed us to link accounts across different authentication methods without user consent. This behavior stemmed from a misconfiguration and custom implementation on top of Auth0’s authentication flow.

---

## Introduction:

Auth0 is a powerful identity platform that simplifies authentication and authorization. While it provides secure building blocks for user identity management, improper configuration or unsafe customizations can introduce serious vulnerabilities.

This case study highlights a real-world misconfiguration that allowed for unintended account linking between users signing in with Google and those using email/password, all tied to the same email address. We break down how we discovered, analyzed, and exploited this issue in detail.

---

## Background: Auth0 Connections & Account Separation:

In Auth0, each authentication method (like Google, email/password, or passwordless) is treated as a separate "connection." By design, when a user signs up using the same email address through different connections, Auth0 creates separate user profiles — each with its own unique `user_id`.

For example:

* Signing up via Google with `vic@vic.vic` creates **Profile A** (e.g., `google-oauth2|xxxxxx`[)](https://kareemelsadek.github.io)
    
* Signing up via passwordless creates **Profile B** (e.g., `email|yyyyyyyy`)
    
* Signing up via email/password creates **Profile C** (e.g., `auth0|zzzzzzzz`)
    

Each profile exists independently unless explicitly linked using the **Account Linking extension** or custom logic.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753687486864/945a8cee-20c6-449e-acf7-50242a495e99.png align="center")

> **Note:** We identified the available `connections` used by the application via a hidden endpoint that we will not disclose here.
> 
> ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753877441175/ba5e1047-2ea0-4841-aa34-4b9937aa63cb.png align="center")

---

## How the Application Broke Auth0's Expected Behavior:

Despite the default behavior of keeping accounts separate per connection, we found that this application linked accounts **implicitly** — specifically when a user logged in via email/password using the same email as an existing Google account.

### Inferred Account Merging Logic

Through deep inspection of the authentication flow and its behavior, we concluded that the application was using **custom logic (likely through an Auth0 Action or Rule)** to merge accounts during the **token generation phase**.

Here’s how it likely worked:

1. User enters valid email/password (for the same email used earlier with Google login).
    
2. Auth0 verifies credentials and generates an authorization code or token.
    
3. **During this exchange**, a custom Action (Auth0 server-side code triggered during the flow) links this new login attempt to the existing Google account.
    
4. The resulting Access Token or ID Token is issued **for the primary account** (the one created via Google)[.](https://kareemelsadek.github.io)
    

This is not default Auth0 behavior and appears to be an intentional but unsafe implementation by the developers.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753687743317/9ca66c4c-84a2-4c4c-a7b0-7bef61da9c9d.png align="center")

---

## Step-by-Step Exploitation:

**Step 1: Create a Primary Account via Google**

We initiated the test by creating an account through the application’s only visible login method: “Sign in with Google.” This created the primary user profile in Auth0.

**Step 2: Discovering the Database Connection**

The app had no visible way to register or log in using email and password. However, we discovered an Auth0 endpoint exposing the valid database connections name — which is required to craft direct API requests.

**Step 3: Bypassing the Frontend and Registering a Second Account**

Once we had the correct `connection` name and `client_id`, we registered a second account using the same email but via the Auth0 `/dbconnections/signup` endpoint:

```http
POST /dbconnections/signup HTTP/2
Host: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXX",
  "email": "testacc2399@gmail.com",
  "password": "testA@123",
  "connection": "app-prod-users",
  "credential_type": "http://auth0.com/oauth/grant-type/password-realm"
}
```

**Step 4: Triggering the Custom Account Linking Logic**

The application didn’t offer an email/password login form, so we manually crafted a login URL targeting the implicit flow. We used the `response_type=token` to request an access token directly — leveraging the fact that **implicit grant** was enabled for this client.

```http
https://auth.app.xx/authorize?client_id=XXXXXXXXXXXX&response_type=token&connection=app-prod-users&prompt=login&scope=openid profile email&redirect_uri=https://app.app.xx/callback
```

Visiting this link displayed a login form (thanks to `prompt=login` and the `connection=xssx`), allowing us to authenticate with the email/password we created in step 3.

![](https://miro.medium.com/v2/resize:fit:700/1*YS68EwzhIah-o9yM1Gml7w.png align="left")

**Step 5: Result — Access Granted to the Google Account**

After logging in using email/password, the access token we received belonged to the **original Google account** — not a new or separate profile.

This confirmed the application’s custom logic forcibly merged the two accounts based solely on email, during the token issuance phase. This type of implicit linking can have serious security consequences.

---

## Possible Root Causes of Implicit Account Linking

While our analysis suggested that a custom Auth0 Action or Rule was merging accounts during token issuance, other misconfigurations could also lead to similar behavior. For instance:

**1\. User Data Retrieval Based on Email**  
Instead of maintaining strict separation between identities from different connections, the application may have been fetching user data based solely on the `email` claim present in the ID Token or Access Token.

* In this scenario, when a new account is created with the same email, the backend retrieves and returns data from the original profile.
    
* This creates the illusion that the attacker is logged in as the victim, even though no explicit account-linking mechanism is in place.
    

This approach bypasses Auth0’s identity model entirely and relies on email as the unique identifier — which is unsafe because multiple identities can legitimately share the same email across different connections.

---

## Conclusion:

Account linking vulnerabilities like this one are subtle but dangerous — and often originate from well-meaning but unsafe developer customizations. By understanding how Auth0 handles identities across connections and being cautious with custom Actions or Rules, developers can avoid introducing this kind of critical logic flaw.

Thanks for reading!