Rendering Bot Detection CAPTCHA inline for a fully embedded (non-Universal-Login) app

Get Help
, ,
1

Hi,

Our app is a fully embedded/custom auth UI — no Universal Login, Lock, auth0.js, or auth0-spa-js. We call the Authentication API directly from our own frontend: Resource Owner Password (realm) grant for login, POST /dbconnections/signup for signup, and POST /dbconnections/change_password for password reset. Bot Detection is enabled on our tenant with “Auth Challenge” selected as the challenge type.

We’d like to render the CAPTCHA challenge inline in our own signup and password-reset forms (instead of redirecting to a hosted Auth0 page) when a request gets flagged. We tried the approach auth0.js’s source implies — calling POST /dbconnections/signup/challenge and POST /dbconnections/change_password/challenge to check required and get a site key before rendering a widget — but both consistently return 404 Not Found regardless of origin or request shape.

We also tested POST /usernamepassword/challenge directly, with a valid, freshly-issued state from our own /authorize call. It still 404s when called from our app’s origin. It only succeeds when we replicate the exact request Auth0’s own hosted login page makes — same-origin, from https://{tenant}.auth0.com itself. Changing only the Origin/Referer to our own domain (with the same, untouched state) is what triggers the 404.

So it appears these challenge endpoints are intentionally locked to Auth0’s own hosted domain, independent of a valid transaction state. Given that:

  1. Is there any supported way for a fully custom, embedded frontend (not using Universal Login) to render Bot Detection’s native CAPTCHA inline — for signup or password-reset specifically? We understand the Resource Owner Password grant explicitly doesn’t support this; is the same true for signup/password-reset, or is there a documented mechanism we’re missing?
  2. If native rendering isn’t possible outside Universal Login, is running an independently-hosted CAPTCHA (e.g. our own Cloudflare Turnstile site, verified server-side by us) before calling /dbconnections/signup / /change_password the recommended pattern for embedded apps in this situation?
3

Hi @platbaseddeveloper

There is no supported way for a fully custom, embedded frontend (calling direct API endpoints like /dbconnections/signup or /dbconnections/change_password) to render or resolve Auth0’s native Bot Detection CAPTCHA inline.

  • The /usernamepassword/challenge, /dbconnections/signup/challenge, and /dbconnections/change_password/challenge endpoints are hard-locked at the edge to Auth0’s own domain. This domain-level restriction is part of Auth0’s security boundary to prevent cross-origin abuse and UI redressing (clickjacking) of CAPTCHA elements.
  • The standard Resource Owner Password Credentials (ROPC) grant explicitly does not support native CAPTCHA challenges. Because of how they operate, the direct database signup and password-reset endpoints behave under the same structural restrictions—there is no mechanism in the direct API to securely transport, solve, and verify an inline CAPTCHA token between a third-party origin and the Auth0 backend.

If your product architecture requires a fully custom/embedded UI (and you cannot migrate to Universal Login), using an independent CAPTCHA provider (e.g., Cloudflare Turnstile, Google reCAPTCHA, or friendly-challenge) on your own servers before invoking Auth0 is the industry-standard and recommended pattern.
Because calling direct Authentication API endpoints from a client-side application leaves you vulnerable to automated signups and credential stuffing, you should shield these endpoints using a backend gateway.

Recommended Implementation Pattern:

  1. Protect your Client-Side Form: Integrate a CAPTCHA widget (like Cloudflare Turnstile or Google reCAPTCHA v3) directly into your custom signup and password-reset pages.

  2. Collect the Token: Prior to submission, have your frontend generate a client-side CAPTCHA token.

  3. Route Through a Backend Proxy (Highly Recommended):
    Instead of exposing the Auth0 Authentication API directly to your client-side app, route your signup and password-reset operations through your own Node/Express backend.

    • Frontend: Sends the user credentials along with the client-side CAPTCHA token to your backend API.

    • Backend (Verification): Your backend makes a secure, server-to-server call to your CAPTCHA provider to verify the token.

    • Backend (Execution): If the verification succeeds, your backend proxies the signup or reset request to Auth0’s Authentication API. If it fails, your backend returns a generic validation error directly to the client without ever hitting Auth0, completely preserving your Auth0 API rate-limiting thresholds and tenant log health.

  4. Configure Tenant-Side Attack Protection:
    Because your backend proxy will handle the CAPTCHA validation, you should go to your Auth0 Dashboard > Security > Attack Protection > Bot Detection and set the response action to “Monitoring”. This ensures that Auth0’s automated edge defenses do not silently block your backend’s proxy requests (which will all come from the same trusted IP/CIDR block).

Kind Regards,
Nik