Exploiting Auth0 Misconfigurations: A Case Study on Account Linking Vulnerabilities

During a comprehensive security assessment of an application using Auth0, my colleague Kareem AlSadeq 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|xxxxxxxx)

• 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.

Note: We identified the available connections used by the application via a hidden endpoint that we will not disclose here.

---

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).

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

---

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:

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.

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.

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.

---

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!