> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Découvrez comment configurer Cloudflare pour l’utiliser comme proxy de domaine personnalisé pour Auth0.
# Configurer Cloudflare comme proxy inverse
Votre forfait Auth0 ou votre entente personnalisée influence la disponibilité de cette fonctionnalité. Pour en savoir plus, consultez [la page de tarification d’Auth0](https://auth0.com/pricing).
Pour configurer Cloudflare comme proxy inverse selon l’approche recommandée, un forfait Enterprise de Cloudflare comprenant les fonctionnalités suivantes est requis :
| Fonctionnalité | Description |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Host Header Override | Permet de réécrire les en-têtes Host à l’aide de différentes règles Cloudflare. Pour en savoir plus, consultez [Rewrite Host headers on Cloudflare Docs](https://developers.cloudflare.com/rules/origin-rules/tutorials/change-uri-path-and-host-header/). |
| True-Client-IP Header | L’activation de l’en-tête True-Client-IP ajoute l’en-tête True-Client-IP à toutes les requêtes envoyées à votre serveur d’origine, y compris l’adresse IP de l’utilisateur final. Pour en savoir plus, consultez [Understanding the True-Client-IP Header on Cloudflare](https://developers.cloudflare.com/network/true-client-ip-header/). |
## Configurer Cloudflare
Comme condition préalable, le domaine parent du domaine personnalisé choisi doit être [ajouté et activé dans le tableau de bord Cloudflare](https://developers.cloudflare.com/learning-paths/get-started/add-domain-to-cf/minimize-downtime/#activate-your-domain). Assurez-vous également que le domaine personnalisé souhaité n’existe pas déjà dans votre zone Cloudflare. S’il existe déjà, la vérification Cloudflare échouera.
Pour configurer Cloudflare comme proxy inverse, vous devrez créer un enregistrement CNAME, une règle de page et une règle de transformation dans Cloudflare.
1. [Configurez et vérifiez un domaine personnalisé avec des certificats autogérés](/docs/fr-ca/customize/custom-domains/self-managed-certificates) si ce n’est pas déjà fait. Prenez note des valeurs **Origin Domain Name** et **cname-api-key**, car vous en aurez besoin plus tard.
2. Dans le tableau de bord Cloudflare de la zone cible, [créez un enregistrement CNAME](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) avec les paramètres suivants :
| Paramètre | Valeur |
| ------------- | ------------------------------------------------ |
| Nom | Le nom de domaine personnalisé. |
| Cible | La valeur **Origin Domain Name** notée plus tôt. |
| État du proxy | `Proxied` |
3. [Créez une règle de page](https://developers.cloudflare.com/rules/page-rules/) qui s’applique à toutes les URL du domaine personnalisé choisi, avec les paramètres suivants :
| Paramètre | Valeur |
| ------------------------------ | ------------------------------------------------ |
| Remplacement de l’en-tête Host | La valeur **Origin Domain Name** notée plus tôt. |
| True-Client-IP | `Enable` |
4. [Créez une règle de transformation](https://developers.cloudflare.com/rules/transform/request-header-modification/create-dashboard/) :
Bien qu’il soit possible d’utiliser des Cloudflare Workers au lieu des règles de page et de transformation pour mettre en place un proxy inverse qui répond aux exigences d’un domaine personnalisé avec certificat autogéré, nous recommandons l’approche fondée sur des règles, car elle évite d’avoir à écrire du code personnalisé.
1. Passez à la vue **Modify Request Header**.
2. Sélectionnez **Create Rule** et donnez-lui le nom de votre choix.
3. Sous **When incoming requests match**, sélectionnez **Custom filter expression** et définissez une expression qui limite la règle aux requêtes associées au domaine personnalisé choisi. Par exemple, utilisez une correspondance exacte sur le champ **Hostname**.
4. Sous **Modify request header**, sélectionnez **Set static**, puis définissez les champs suivants :
| Champ | Valeur |
| ---------------- | ------------------------------------------- |
| Nom de l’en-tête | `cname-api-key` |
| Valeur | La valeur **cname-api-key** notée plus tôt. |
5. Assurez-vous que [Always Use HTTPS](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/always-use-https/) est activé et que le [mode de chiffrement](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/) est réglé au minimum sur **Full** pour le domaine personnalisé choisi.
## Utiliser Managed Challenges
Les [Managed Challenges](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/#managed-challenges) de Cloudflare vous permettent de filtrer le trafic de bots avant que les requêtes n’atteignent Auth0 Universal Login. Lorsqu’une requête correspond à votre règle, Cloudflare l’intercepte et présente une vérification. Comme les pages de challenge renvoient du HTML, Managed Challenges ne sont compatibles qu’avec les flux dans le navigateur — les appliquer à des points de terminaison d’API ou à des flux sans interface utilisateur les fera échouer, car le client recevra une page de challenge HTML au lieu de la réponse attendue.
### Points de terminaison Universal Login basés sur le navigateur
Les points de terminaison suivants servent des pages HTML à un navigateur et sont compatibles avec Managed Challenges :
| Point de terminaison | Description |
| ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| `/u/email-verification` | Vérification de l’adresse courriel |
| `/u/login` | Écrans d’identifiant et d’identifiant d’abord |
| Points de terminaison d’organisation :
- `u/organization`
- `/u/organization-picker`
- `/u/pre-organization-picker`
| Écrans de sélection d’organisation |
| `/u/login/password` | Écran de mot de passe |
| `/u/login-email-verification` | Écran de vérification de l’adresse courriel |
| `/u/signup` | Écrans d’identifiant |
| `/u/signup/password` | Écran de mot de passe |
| `/u/consent` | Écran de consentement |
| `/u/customized-consent` | Écran de consentement personnalisé |
| `/u/reset-password` | Écrans de réinitialisation du mot de passe |
| `/u/reset-password/request` | Écran d’e-mail/nom d’utilisateur pour la réinitialisation du mot de passe |
| `/u/reset-password/change` | Écran de nouveau mot de passe |
| `/u/reset-verify` | Vérification de la réinitialisation du mot de passe |
| `/u/mfa-begin-enroll-options` | Sélection du facteur d’inscription MFA |
| `/u/mfa-enroll-options` | Options d’inscription MFA |
| `/u/mfa-otp` | Écrans de mot de passe à usage unique |
| `/u/mfa-push` | Écrans de notification poussée |
| `/u/mfa-webauthn` | Écrans WebAuthn et de clé d’accès |
| `/u/mfa-recovery-code` | Écrans de code de récupération |
| `/u/mfa-sms` | Écrans SMS |
| `/u/mfa-email` | Écrans d’e-mail MFA |
| `/u/mfa-voice` | Écrans vocaux MFA |
| `/u/passkey-enrollment` | Inscription de clé d’accès |
Si vous utilisez Classic Universal Login, incluez aussi `/login` dans votre règle Managed Challenge.
### Points de terminaison à exclure
N’appliquez pas de Managed Challenge aux points de terminaison suivants. Ils sont appelés par des serveurs, des SDKs ou des serveurs de ressources et ne peuvent pas relever un défi interactif :
| Point de terminaison | Description |
| ----------------------------------- | --------------------------------------------------------------------------------------- |
| `/oauth/token` | Point de terminaison de jeton |
| `/oauth/revoke` | Point de terminaison de révocation de jeton |
| `/userinfo` | Point de terminaison UserInfo |
| `/.well-known/openid-configuration` | Document de découverte OIDC |
| `/.well-known/jwks.json` | JSON Web Key Set; récupéré par les serveurs de ressources pour la validation des jetons |
| `/api/v2/*` | Management API |
| `/co/authenticate` | Authentification inter-origines |
| `/dbconnections/signup` | Connexions de base de données : inscription |
| `/dbconnections/change_password` | Connexions de base de données : changement de mot de passe |
| `/usernamepassword/login` | Classic Universal Login : soumission du formulaire |
| `/mfa/challenge` | Demande de challenge |
| `/mfa/associate` | Association d’un authentificateur |
| `/passwordless/start` | Passwordless : requête d’initialisation |
| `/samlp/*` | Points de terminaison du protocole SAML |
| `/wsfed/*` | Points de terminaison WS-Federation |
| `/v2/logout` | Peut être appelé côté serveur dans des flux de Back-Channel Logout |
### Exemple de règle
Pour appliquer les Managed Challenges uniquement aux flux Universal Login dans le navigateur, créez une [WAF Custom Rule](https://developers.cloudflare.com/waf/custom-rules/) dans Cloudflare. Définissez l’action de la règle sur **Managed Challenge** et utilisez l’expression suivante en remplaçant `YOUR_CUSTOM_DOMAIN` par votre domaine personnalisé (par exemple, `login.example.com`) :
```text theme={null}
(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"
))
```
Cela limite cette mesure aux seuls points de terminaison Universal Login avec interface utilisateur et évite de perturber le trafic d’API et de machine à machine.
Quelques cas d’utilisation peuvent se comporter différemment :
* **Persistance du cookie d’autorisation** : Une fois qu’un navigateur a franchi un Managed Challenge, Cloudflare émet un cookie d’autorisation qui persiste généralement pendant la session. Selon votre configuration, limiter la règle à `/authorize` בלבד peut suffire pour couvrir l’ensemble du flux de connexion Universal Login sans l’appliquer à chaque chemin `/u/*`.
* **Points d’entrée non OAuth** : Les flux qui commencent à partir de points d’entrée SAML initiés par le fournisseur de services (SP) ou de points d’entrée WS-Federation utilisent `/samlp/*` ou `/wsfed/*` au lieu de `/authorize`. Ces chemins figurent dans la liste d’exclusion et ne devraient pas être soumis à un Managed Challenge.
## Configurer Auth0
Appelez le point de terminaison [Mettre à jour la configuration du domaine personnalisé](https://auth0.com/docs/api/management/v2#!/Custom_Domains/patch_custom_domains_by_id) de l’Management API d’Auth0 avec la charge utile suivante dans le corps de la requête :
```json lines theme={null}
{
"custom_client_ip_header": "true-client-ip"
}
```
Auth0 sera ainsi configuré pour extraire l’adresse IP de l’utilisateur final de l’en-tête HTTP `true-client-ip`.
Utilisez toujours `true-client-ip` dans la mesure du possible. Cloudflare ne prend pas en charge l’utilisation de l’en-tête HTTP `cf-connecting-ip` à cette fin.
## En savoir plus
* [Configurer les fonctionnalités pour utiliser des domaines personnalisés](/docs/fr-ca/customize/custom-domains/configure-features-to-use-custom-domains)
* [Versions TLS (SSL) et suites de chiffrement](/docs/fr-ca/customize/custom-domains/self-managed-certificates/tls-ssl)