79| Champ | Obligatoire | Description |79| Champ | Obligatoire | Description |
80| - | - | - |80| - | - | - |
81| `issuer` | Oui | Base de découverte OIDC. Doit servir la découverte à `/.well-known/openid-configuration`. Utilisez HTTPS en production ; la passerelle accepte un émetteur `http://`. Un émetteur loopback tel que `http://localhost:8081` est rejeté par la [protection SSRF](/docs/fr/claude-apps-gateway-deploy#threat-model-summary) sauf si `CLAUDE_GATEWAY_ALLOW_LOOPBACK=1` est défini dans l'environnement de la passerelle. |81| `issuer` | Oui | Base de découverte OIDC. Doit servir la découverte à `/.well-known/openid-configuration`. Utilisez HTTPS en production ; la passerelle accepte un émetteur `http://`. Un émetteur loopback tel que `http://localhost:8081` est rejeté par la [protection SSRF](/docs/fr/claude-apps-gateway-deploy#threat-model-summary) sauf si `CLAUDE_GATEWAY_ALLOW_LOOPBACK=1` est défini dans l'environnement de la passerelle. |
82| `client_id` / `client_secret` | Oui | À partir de votre enregistrement de client OAuth |82| `client_id` | Oui | À partir de votre enregistrement de client OAuth |
83| `client_secret` | Sauf si `token_endpoint_auth_method` est `private_key_jwt` | À partir de votre enregistrement de client OAuth. Omettez-le lorsque vous utilisez l'[authentification client par certificat](#certificate-client-authentication). |
83| `allowed_email_domains` | Non | Rejeter les id\_tokens dont la revendication `email` n'est pas dans l'un de ces domaines, insensible à la casse. Défense en profondeur contre les erreurs de configuration du fournisseur d'identité multi-locataire. Indépendamment de ce paramètre, un id\_token dont la revendication `email_verified` est explicitement `false` est toujours rejeté. |84| `allowed_email_domains` | Non | Rejeter les id\_tokens dont la revendication `email` n'est pas dans l'un de ces domaines, insensible à la casse. Défense en profondeur contre les erreurs de configuration du fournisseur d'identité multi-locataire. Indépendamment de ce paramètre, un id\_token dont la revendication `email_verified` est explicitement `false` est toujours rejeté. |
84| `allowed_groups` | Non | Restreindre la connexion aux membres de ces groupes du fournisseur d'identité, comparés à `groups_claim`. Un utilisateur dans un domaine d'e-mail autorisé mais dans aucun de ces groupes est rejeté. Nécessite que le fournisseur d'identité émette la revendication de groupes. La correspondance est une comparaison de chaîne exacte et sensible à la casse par rapport aux valeurs de cette revendication, et la passerelle n'étend pas les groupes imbriqués : pour admettre les membres d'un sous-groupe, listez le sous-groupe ici ou configurez le fournisseur d'identité pour émettre l'appartenance aplatie. |85| `allowed_groups` | Non | Restreindre la connexion aux membres de ces groupes du fournisseur d'identité, comparés à `groups_claim`. Un utilisateur dans un domaine d'e-mail autorisé mais dans aucun de ces groupes est rejeté. Nécessite que le fournisseur d'identité émette la revendication de groupes. La correspondance est une comparaison de chaîne exacte et sensible à la casse par rapport aux valeurs de cette revendication, et la passerelle n'étend pas les groupes imbriqués : pour admettre les membres d'un sous-groupe, listez le sous-groupe ici ou configurez le fournisseur d'identité pour émettre l'appartenance aplatie. |
85| `groups_claim` | Non | Quelle revendication id\_token porte l'appartenance au groupe. Par défaut `groups`. Microsoft Entra émet les rôles d'application sous `roles`. Accepte une clé plate ou un pointeur JSON RFC 6901 tel que `/resource_access/gateway/roles` pour les revendications imbriquées. |86| `groups_claim` | Non | Quelle revendication id\_token porte l'appartenance au groupe. Par défaut `groups`. Microsoft Entra émet les rôles d'application sous `roles`. Accepte une clé plate ou un pointeur JSON RFC 6901 tel que `/resource_access/gateway/roles` pour les revendications imbriquées. |
91| `userinfo_fallback` | Non | Lorsque le id\_token omet l'e-mail ou les groupes, les récupérer à partir de `/userinfo`. Nécessaire pour les jetons d'accès légers Keycloak, le serveur org Okta, et les jetons minimaux ADFS. Le id\_token reste faisant autorité ; userinfo remplit uniquement les lacunes. Par défaut `false`. |92| `userinfo_fallback` | Non | Lorsque le id\_token omet l'e-mail ou les groupes, les récupérer à partir de `/userinfo`. Nécessaire pour les jetons d'accès légers Keycloak, le serveur org Okta, et les jetons minimaux ADFS. Le id\_token reste faisant autorité ; userinfo remplit uniquement les lacunes. Par défaut `false`. |
92| `use_pkce` | Non | Envoyer un défi PKCE (S256) sur la demande d'autorisation. Par défaut `true`. Définissez `false` uniquement si votre fournisseur d'identité rejette PKCE pour ce client confidentiel. |93| `use_pkce` | Non | Envoyer un défi PKCE (S256) sur la demande d'autorisation. Par défaut `true`. Définissez `false` uniquement si votre fournisseur d'identité rejette PKCE pour ce client confidentiel. |
93| `clock_skew_seconds` | Non | Tolérer la dérive d'horloge lors de la validation des revendications de temps id\_token. Par défaut `0`, ce qui est strict. Augmentez si vous voyez des erreurs « token expired / not yet valid » juste après la connexion en raison d'une dérive d'horloge hôte/fournisseur d'identité. |94| `clock_skew_seconds` | Non | Tolérer la dérive d'horloge lors de la validation des revendications de temps id\_token. Par défaut `0`, ce qui est strict. Augmentez si vous voyez des erreurs « token expired / not yet valid » juste après la connexion en raison d'une dérive d'horloge hôte/fournisseur d'identité. |
94| `token_endpoint_auth_method` | Non | Remplacer la méthode d'authentification du point de terminaison de jeton. Accepte `client_secret_basic` ou `client_secret_post`. Négocié automatiquement par défaut. |95| `token_endpoint_auth_method` | Non | Comment la passerelle s'authentifie auprès de l'endpoint de jeton du fournisseur d'identité : `client_secret_basic`, `client_secret_post`, ou `private_key_jwt` pour l'[authentification client par certificat](#certificate-client-authentication). Par défaut, la passerelle choisit l'une des deux méthodes `client_secret` en fonction de ce que le fournisseur d'identité annonce. |
96| `client_assertion` | Avec `private_key_jwt` | Un bloc avec `private_key_pem` et `certificate_pem` : la clé privée et le certificat pour l'[authentification client par certificat](#certificate-client-authentication). Nécessite v2.1.284 ou ultérieur. |
95| `id_token_signed_response_alg` | Non | Algorithme de signature id\_token attendu. Par défaut `RS256`. Définissez pour les fournisseurs d'identité qui signent avec ES256, PS256, ou EdDSA. |97| `id_token_signed_response_alg` | Non | Algorithme de signature id\_token attendu. Par défaut `RS256`. Définissez pour les fournisseurs d'identité qui signent avec ES256, PS256, ou EdDSA. |
96| `additional_authorized_parties` | Non | Valeurs `azp` supplémentaires à accepter au-delà de `client_id`, pour les flux de courtier Keycloak et d'échange de jetons |98| `additional_authorized_parties` | Non | Valeurs `azp` supplémentaires à accepter au-delà de `client_id`, pour les flux de courtier Keycloak et d'échange de jetons |
97| `discovery_url` | Non | Récupérer le document de découverte à partir de cette URL au lieu de le dériver de `issuer`, pour les fournisseurs d'identité derrière un proxy qui réécrit l'hôte émetteur. Le chemin doit contenir `/.well-known/`. |99| `discovery_url` | Non | Récupérer le document de découverte à partir de cette URL au lieu de le dériver de `issuer`, pour les fournisseurs d'identité derrière un proxy qui réécrit l'hôte émetteur. Le chemin doit contenir `/.well-known/`. |
99| `form_action_origins` | Non | Origines supplémentaires pour la directive `Content-Security-Policy: form-action` de la page `/device`. La passerelle autorise déjà `'self'` et l'origine `authorization_endpoint` découverte, mais Chrome applique `form-action` à toute la chaîne de redirection. Si votre fournisseur d'identité redirige via un deuxième hôte, tel qu'Azure AD fédéré à ADFS, Okta hub-spoke, ou un intercepteur SSO d'entreprise, listez chaque origine par laquelle la demande d'autorisation peut rediriger. |101| `form_action_origins` | Non | Origines supplémentaires pour la directive `Content-Security-Policy: form-action` de la page `/device`. La passerelle autorise déjà `'self'` et l'origine `authorization_endpoint` découverte, mais Chrome applique `form-action` à toute la chaîne de redirection. Si votre fournisseur d'identité redirige via un deuxième hôte, tel qu'Azure AD fédéré à ADFS, Okta hub-spoke, ou un intercepteur SSO d'entreprise, listez chaque origine par laquelle la demande d'autorisation peut rediriger. |
100| `ca_cert_pem` | Non | Le certificat CA codé en PEM lui-même, pas un chemin vers un fichier. Il remplace le magasin de confiance du système pour les demandes du fournisseur d'identité uniquement. Pour charger un fichier monté, écrivez `${file:/etc/gateway/idp-ca.pem}`. Utilisez pour Keycloak ou Dex derrière une PKI d'entreprise. |102| `ca_cert_pem` | Non | Le certificat CA codé en PEM lui-même, pas un chemin vers un fichier. Il remplace le magasin de confiance du système pour les demandes du fournisseur d'identité uniquement. Pour charger un fichier monté, écrivez `${file:/etc/gateway/idp-ca.pem}`. Utilisez pour Keycloak ou Dex derrière une PKI d'entreprise. |
101 103
104<h4 id="certificate-client-authentication">
105 Authentification client par certificat
106</h4>
107
108Si votre fournisseur d'identité authentifie les clients OAuth avec un certificat au lieu d'un secret client, comme le fait Microsoft Entra avec les identifiants de certificat, définissez `token_endpoint_auth_method: private_key_jwt`. Nécessite Claude Code v2.1.284 ou ultérieur sur le serveur de la passerelle.
109
110Avec cette configuration, la passerelle n'envoie aucun secret. Elle s'authentifie auprès de l'endpoint de jeton du fournisseur d'identité avec un JWT de courte durée signé avec la clé privée du certificat lorsqu'un développeur se connecte et chaque fois que la passerelle actualise sa session. Le JWT est signé avec RS256 et identifie le certificat par les en-têtes d'empreinte `x5t` et `x5t#S256` plutôt que par un `kid`. Votre fournisseur d'identité doit pouvoir trouver le certificat enregistré par son empreinte.
111
112<Steps>
113 <Step title="Créer la clé et le certificat">
114 Créez une clé privée RSA non chiffrée d'au moins 2048 bits, au format PEM PKCS#8 ou PKCS#1, et un certificat pour celle-ci. La passerelle refuse de démarrer avec toute clé qui ne remplit pas ces conditions. Cette commande `openssl` crée une telle clé avec un certificat auto-signé valide pendant un an :
115
116 ```bash theme={null}
117 openssl req -x509 -newkey rsa:2048 -nodes -keyout idp-client.key -out idp-client.crt -days 365 -subj "/CN=claude-gateway"
118 ```
119
120 Elle écrit `idp-client.key` et `idp-client.crt` dans le répertoire courant. Copiez ou montez les deux fichiers à un emplacement où la passerelle peut les lire. L'exemple de l'étape 3 utilise `/etc/gateway/`.
121 </Step>
122
123 <Step title="Téléverser le certificat vers le fournisseur d'identité">
124 Téléversez le certificat, et non la clé privée, dans l'enregistrement d'application de la passerelle auprès du fournisseur d'identité.
125 </Step>
126
127 <Step title="Ajouter la clé et le certificat à gateway.yaml">
128 Fournissez à la passerelle la clé privée et le certificat dans un bloc `client_assertion`. Omettez `client_secret`, car la passerelle refuse de démarrer lorsqu'un secret est défini en même temps que `private_key_jwt`. Ce bloc `oidc` authentifie la passerelle auprès d'un locataire Microsoft Entra avec un certificat :
129
130 ```yaml theme={null}
131 oidc:
132 issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
133 client_id: <application-id>
134 token_endpoint_auth_method: private_key_jwt
135 client_assertion:
136 private_key_pem: ${file:/etc/gateway/idp-client.key}
137 certificate_pem: ${file:/etc/gateway/idp-client.crt}
138 ```
139
140 Les deux valeurs sont le contenu PEM, et non des chemins de fichiers, donc chargez les fichiers montés avec `${file:/path}` comme le fait l'exemple. La passerelle refuse de démarrer sauf si `certificate_pem` est un certificat PEM unique, sans le reste de sa chaîne, dont la clé publique correspond à `private_key_pem`.
141 </Step>
142
143 <Step title="Redémarrer la passerelle et vérifier le log de démarrage">
144 Redémarrez la passerelle et repérez cette ligne dans le log de démarrage :
145
146 ```text theme={null}
147 [gateway] 2026-10-01T23:07:40.512Z info oidc: client authentication private_key_jwt; certificate CN=claude-gateway, SHA-1 thumbprint DE92821854EE8BAA1D98C758FAA04AABE80B9F57, expires Oct 1 23:07:31 2027 GMT
148 ```
149
150 Comparez l'empreinte SHA-1 avec celle que le fournisseur d'identité affiche pour le certificat que vous avez téléversé. Si le certificat a expiré ou n'est pas encore valide, la passerelle démarre quand même mais journalise un avertissement indiquant que les connexions et les actualisations échoueront jusqu'à ce que vous le remplaciez. Pour confirmer que le fournisseur d'identité accepte le certificat, demandez à un développeur de se connecter via la passerelle.
151 </Step>
152</Steps>
153
154<h4 id="rotate-the-client-certificate">
155 Faire tourner le certificat client
156</h4>
157
158La passerelle lit la clé et le certificat une seule fois au démarrage, donc un fichier modifié ne prend effet qu'après un redémarrage. Effectuez la rotation dans cet ordre afin qu'aucune requête de jeton ne présente un certificat dont le fournisseur d'identité ne dispose pas :
159
1601. Téléversez le nouveau certificat vers le fournisseur d'identité à côté de l'ancien.
1612. Remplacez les fichiers de clé et de certificat que `gateway.yaml` charge, puis redémarrez la passerelle.
1623. Supprimez l'ancien certificat du fournisseur d'identité.
163
102<h4 id="idp-requests-through-a-forward-proxy">164<h4 id="idp-requests-through-a-forward-proxy">
103 Demandes du fournisseur d'identité via un proxy avant165 Demandes du fournisseur d'identité via un proxy avant
104</h4>166</h4>
