By 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. In Auth0,ApplicationsandAPIsare core concepts that define how users authenticate and how resources are protected. AnAuth0 Applicationrepresents 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. AnAuth0 APIrepresents 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 usingoauth2-proxy, which is configured to authenticate users via anAuth0 regular applicationusing theAuthorization Code Grant Flow. The Admin SPA uses anAuth0 SPA Applicationand theAuthorization 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 ofhttps://admin.auth0-misconfig.local. The backend API only has a/adminendpoint, that validates thesubclaim 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. With the example environment used in this article, the goal is to leverage the XSS vulnerability onvuln.auth0-misconfig.localto pivot toadmin.auth0-misconfig.localand gain access to the/adminendpoint. To achieve this, the XSS exploitvuln.auth0-misconfig.localwould need to retrieve an access token with an audience forhttps://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 theauthorized 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-proxyissues 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 theImplicit Grant Flowto 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, theinsecure flow remains enabled by default in Auth0 applications, with the setting buried underSettings->Advanced Settings->Grant Types, as illustrated in the screenshot below. The Implicit Grant Flow could be initiated using the/authorizeendpoint on an Auth0 Authorization server setting theaudienceand theresponse_type=tokenparameters, as shown in the example authorize endpoint below. Because theoauth2-proxyand 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 aiframeor opening a new window usingwindow.openand 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.