Skip to main content

Availability varies by Auth0 plan

Your Auth0 plan or custom agreement affects the availability of this feature. To learn more, read Auth0’s Pricing Page.
To set up Cloudflare as a reverse proxy using the recommended approach, a Cloudflare Enterprise Plan with the following features is required:

​
Configure Cloudflare

As a prerequisite, the parent domain for your chosen custom domain must be added and activated within the Cloudflare dashboard. Also, confirm that your desired custom domain does not already exist within your Cloudflare zone. If it already exists, Cloudflare verification will fail.
To configure Cloudflare as a reverse proxy, you’ll need to create a CNAME record, a Page Rule, and a Transform Rule in Cloudflare.
  1. Configure and verify a Custom Domain with Self-Managed Certificates if you haven’t already. Make note of the Origin Domain Name and cname-api-key values since you’ll need these later.
  2. In the Cloudflare dashboard for the target zone, create a CNAME record with the following settings:
  3. Create a Page Rule scoped to all URLs under the chosen custom domain and with the following settings:
  4. Create a Transform Rule:
    While it is possible to use Cloudflare Workers instead of Page and Transform rules to set up a reverse proxy that meets the requirements for a self-managed certificate custom domain, we recommend using the rules-based approach because it eliminates the need for custom code.
    1. Switch to the Modify Request Header view.
    2. Select Create Rule and provide a name of your choice.
    3. Under When incoming requests match, select Custom filter expression and set an expression that scopes the Rule to requests associated with the chosen custom domain. For example, use an exact match on the Hostname field.
    4. Under Modify request header, select Set static, and then set the following fields:
  5. Ensure that Always Use HTTPS is enabled and encryption mode is set, at least, to Full for your chosen custom domain.

​
Use Managed Challenges

Cloudflare’s Managed Challenges let you filter bot traffic before requests reach Auth0 Universal Login. When a request matches your rule, Cloudflare intercepts it and presents a verification challenge. Because challenge pages return HTML, Managed Challenges are only compatible with browser-based flows — applying them to API endpoints or headless flows will break those flows because the client receives an HTML challenge page instead of the expected response.

​
Universal Login browser-based endpoints

The following endpoints serve HTML pages to a browser and are compatible with Managed Challenges:
If you use Classic Universal Login, also include /login in your Managed Challenge rule.

​
Endpoints to exclude

Do not apply a Managed Challenge to the following endpoints. These are called by servers, SDKs, or resource servers and cannot solve an interactive challenge:

​
Example rule

To apply Managed Challenges only to browser-based Universal Login flows, create a WAF Custom Rule in Cloudflare. Set the rule action to Managed Challenge and use the following expression, replacing YOUR_CUSTOM_DOMAIN with your custom domain (for example, login.example.com):
This scopes the challenge to headed Universal Login endpoints only and prevents disruption to API and machine-to-machine traffic.
A few use cases may behave differently:
  • Clearance cookie persistence: Once a browser solves a Managed Challenge, Cloudflare issues a clearance cookie that typically persists for the session. Depending on your configuration, scoping the rule to /authorize alone may be sufficient to cover the full Universal Login flow without applying it to every /u/* path.
  • Non-OAuth entry points: Flows that start from SAML SP-initiated or WS-Federation entry points use /samlp/* or /wsfed/* instead of /authorize. These paths are in the exclusion list and should not have a Managed Challenge applied to them.

​
Configure Auth0

Call the Auth0 Update custom domain configuration endpoint with the following payload in the body:

​
Learn more