Configurar Cloudflare como proxy inverso

Aprenda a configurar Cloudflare para usarlo como proxy de dominio personalizado para Auth0.

La disponibilidad varía según el plan de Auth0

La disponibilidad de esta función depende de su plan de Auth0 o de su acuerdo personalizado. Para obtener más información, consulte la página de precios de Auth0.

Para configurar Cloudflare como proxy inverso con el enfoque recomendado, se requiere un plan Enterprise de Cloudflare con las siguientes funciones:

Característica	Descripción
Host Header Override	Permite reescribir los encabezados Host mediante distintas reglas de Cloudflare. Para obtener más información, consulte Rewrite Host headers en la documentación de Cloudflare.
True-Client-IP Header	Al habilitar el encabezado True-Client-IP, este se agrega a todas las solicitudes a su servidor de origen e incluye la dirección IP del usuario final. Para obtener más información, consulte Información sobre el encabezado True-Client-IP en Cloudflare.

​

Configurar Cloudflare

Como requisito previo, el dominio principal del dominio personalizado que elija debe agregarse y activarse en el panel de Cloudflare. Además, confirme que el dominio personalizado que desea usar no exista ya en su zona de Cloudflare. Si ya existe, la verificación de Cloudflare fallará.

Para configurar Cloudflare como proxy inverso, deberá crear un registro CNAME, una Page Rule y una Transform Rule en Cloudflare.

1. Configure y verifique un dominio personalizado con certificados autogestionados si todavía no lo ha hecho. Tome nota de los valores Origin Domain Name y cname-api-key, ya que los necesitará más adelante.

2. En el panel de Cloudflare de la zona de destino, cree un registro CNAME con la siguiente configuración:

   Configuración	Valor
   Nombre	El nombre del dominio personalizado.
   Destino	El valor de Origin Domain Name que anotó anteriormente.
   Estado del proxy	Proxied

3. Cree una Page Rule que se aplique a todas las URL del dominio personalizado elegido y con la siguiente configuración:

   Configuración	Valor
   Host Header Override	El valor de Origin Domain Name que anotó anteriormente.
   True-Client-IP	Enable

4. Cree una Transform Rule:

   Aunque es posible usar Cloudflare Workers en lugar de Page Rules y Transform Rules para configurar un proxy inverso que cumpla los requisitos de un dominio personalizado con certificado autogestionado, recomendamos usar el enfoque basado en reglas porque elimina la necesidad de código personalizado.

   1. Cambie a la vista Modify Request Header.

   2. Seleccione Create Rule y asígnele el nombre que prefiera.

   3. En When incoming requests match, seleccione Custom filter expression y defina una expresión que limite la regla a las solicitudes asociadas con el dominio personalizado elegido. Por ejemplo, use una coincidencia exacta en el campo Hostname.

   4. En Modify request header, seleccione Set static y, a continuación, establezca los siguientes campos:

      Campo	Valor
      Nombre del encabezado	cname-api-key
      Valor	El valor de cname-api-key que anotó anteriormente.

5. Asegúrese de que Always Use HTTPS esté habilitado y de que el modo de cifrado esté configurado, como mínimo, en Full para el dominio personalizado elegido.

​

Usar Managed Challenges

Los Managed Challenges de Cloudflare le permiten filtrar el tráfico de bots antes de que las solicitudes lleguen a Auth0 Universal Login. Cuando una solicitud coincide con su regla, Cloudflare la intercepta y presenta un desafío de verificación. Como las páginas de desafío devuelven HTML, los Managed Challenges solo son compatibles con flujos basados en navegador; si se aplican a endpoints de API o a flujos sin interfaz, esos flujos dejarán de funcionar porque el cliente recibe una página HTML de desafío en lugar de la respuesta esperada.

​

Endpoints de Universal Login para navegador

Los siguientes endpoints sirven páginas HTML en un navegador y son compatibles con Managed Challenges:

Endpoint	Descripción
/u/email-verification	Verificación de correo electrónico
/u/login	Pantallas de identificador y de identificador primero
Endpoints de organización: u/organization /u/organization-picker /u/pre-organization-picker	Pantallas de selección de organización
/u/login/password	Pantalla de contraseña
/u/login-email-verification	Pantalla de verificación de correo electrónico
/u/signup	Pantallas de identificador
/u/signup/password	Pantalla de contraseña
/u/consent	Pantalla de consentimiento
/u/customized-consent	Pantalla de consentimiento personalizado
/u/reset-password	Pantallas de restablecimiento de contraseña
/u/reset-password/request	Pantalla de correo electrónico o username para restablecer la contraseña
/u/reset-password/change	Pantalla de nueva contraseña
/u/reset-verify	Verificación de restablecimiento de contraseña
/u/mfa-begin-enroll-options	Selección del factor de inscripción en MFA
/u/mfa-enroll-options	Opciones de inscripción en MFA
/u/mfa-otp	Pantallas de OTP
/u/mfa-push	Pantallas de notificaciones push
/u/mfa-webauthn	Pantallas de WebAuthn y passkeys
/u/mfa-recovery-code	Pantallas de código de recuperación
/u/mfa-sms	Pantallas de SMS
/u/mfa-email	Pantallas de correo electrónico para MFA
/u/mfa-voice	Pantallas de voz para MFA
/u/passkey-enrollment	Inscripción de passkeys

Si usas Classic Universal Login, incluye también /login en tu regla de Managed Challenge.

​

Endpoints que se deben excluir

No aplique un Managed Challenge a los siguientes endpoints. Los llaman servidores, SDKs o servidores de recursos, y no pueden resolver un desafío interactivo:

Endpoint	Descripción
/oauth/token	Endpoint de token
/oauth/revoke	Endpoint de revocación de token
/userinfo	Endpoint de UserInfo
/.well-known/openid-configuration	Documento de descubrimiento de OIDC
/.well-known/jwks.json	JSON Web Key Set; los servidores de recursos lo recuperan para validar tokens
/api/v2/*	Management API
/co/authenticate	Autenticación de origen cruzado
/dbconnections/signup	Conexiones de base de datos: registro
/dbconnections/change_password	Conexiones de base de datos: cambio de contraseña
/usernamepassword/login	Envío del formulario de Classic Universal Login
/mfa/challenge	Solicitud de desafío
/mfa/associate	Asociación de autenticador
/passwordless/start	Sin contraseña: solicitud de inicio
/samlp/*	Endpoints del protocolo SAML
/wsfed/*	Endpoints de WS-Federation
/v2/logout	Se puede llamar del lado del servidor en flujos de cierre de sesión por canal de retorno

​

Regla de ejemplo

Para aplicar los Managed Challenges solo a los flujos de Universal Login en el navegador, cree una regla personalizada de WAF en Cloudflare. Configure la acción de la regla como Managed Challenge y use la siguiente expresión; sustituya YOUR_CUSTOM_DOMAIN por su dominio personalizado (por ejemplo, login.example.com):

(http.host eq "YOUR_CUSTOM_DOMAIN" and (
  http.request.uri.path eq "/authorize" or
  starts_with(http.request.uri.path, "/u/") or
  http.request.uri.path eq "/login"
))

Esto restringe el desafío únicamente a los endpoints de Universal Login con interfaz de usuario y evita interrumpir el tráfico de la API y de máquina a máquina.

Algunos casos de uso pueden comportarse de forma diferente:

• Persistencia de la cookie de validación: Una vez que un navegador resuelve un Managed Challenge, Cloudflare emite una cookie de validación que normalmente persiste durante la sesión. Según su configuración, limitar la regla solo a /authorize puede ser suficiente para cubrir todo el flujo de Universal Login sin aplicarla a cada ruta /u/*.
• Puntos de entrada no OAuth: Los flujos que comienzan en puntos de entrada de SAML iniciados por el SP o de WS-Federation usan /samlp/* o /wsfed/* en lugar de /authorize. Estas rutas están en la lista de exclusión y no se les debe aplicar un Managed Challenge.

​

Configurar Auth0

Llama al endpoint Update custom domain configuration de la Management API de Auth0 con la siguiente carga útil en el cuerpo:

{
  "custom_client_ip_header": "true-client-ip"
}

​

Más información

• Configurar funciones para usar dominios personalizados
• Versiones y conjuntos de cifrado de TLS (SSL)