> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configurer la PKCE et le mappage des demandes pour les connexions OIDC

> Configurez la preuve de Proof Key for Code Exchange (PKCE) et les modèles de mappage pour les connexions OpenID Connect et Okta Workforce.

export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
  const [displayText, setDisplayText] = useState(children);
  const [copyText, setCopyText] = useState(children);
  const wrapperRef = React.useRef(null);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      if (!window.autorun || !window.rootStore) {
        return;
      }
      unsubscribe = window.autorun(() => {
        let processedChildrenForDisplay = children;
        let processedChildrenForCopy = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`);
          let displayValue = value;
          if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") {
            displayValue = value.substring(0, 3) + "*****MASKED*****";
          }
          processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue);
          processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value);
        }
        setDisplayText(processedChildrenForDisplay);
        setCopyText(processedChildrenForCopy);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  useEffect(() => {
    if (!wrapperRef.current) return;
    const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard);
    let isOverriding = false;
    const handleClick = e => {
      const button = e.target.closest('[data-testid="copy-code-button"]');
      if (!button || !wrapperRef.current.contains(button)) return;
      isOverriding = true;
      navigator.clipboard.writeText = text => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
          return originalWriteText(copyText);
        }
        return originalWriteText(text);
      };
      setTimeout(() => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
        }
      }, 100);
    };
    const wrapper = wrapperRef.current;
    wrapper.addEventListener('click', handleClick, true);
    return () => {
      wrapper.removeEventListener('click', handleClick, true);
      if (navigator.clipboard.writeText !== originalWriteText) {
        navigator.clipboard.writeText = originalWriteText;
      }
    };
  }, [copyText]);
  return <div ref={wrapperRef}>
      <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
        {displayText}
      </CodeBlock>
    </div>;
};

export const codeExample1 = `curl --request POST \
--url 'https://{yourDomain}/api/v2/connections' \
--header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
--data '{
  "strategy": "oidc",
   "name": "CONNECTION_NAME",
   "options": {
     "type": "back_channel",
     "discovery_url": "https://IDP_DOMAIN/.well-known/openid-configuration",
     "client_id" : "IDP_CLIENT_ID",
     "client_secret" : "IDP_CLIENT_SECRET",
     "scopes": "openid profile",
     "connection_settings": { "pkce": "auto" }
               }
          }'`;

export const codeExample2 = `curl --request POST \
  --url 'https://{yourDomain}/api/v2/connections' \
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  --data '{
    "strategy": "oidc",
    "name": "CONNECTION_NAME",
    "options": {
      "type": "back_channel",
      "client_id": "IDP_CLIENT_ID",
      "client_secret": "IDP_CLIENT_SECRET",
      "connection_settings": { "pkce": "auto" },
      "issuer": "https://IDP_DOMAIN",
      "authorization_endpoint": "https://IDP_DOMAIN/authorize",
      "jwks_uri": "https://IDP_DOMAIN/.well-known/jwks.json",
      "scopes": "openid profile",
      "oidc_metadata": {
        "issuer": "https://IDP_DOMAIN",
        "authorization_endpoint": "https://IDP_DOMAIN/authorize",
        "jwks_uri": "https://IDP_DOMAIN/.well-known/jwks.json",
        "token_endpoint": "https://IDP_DOMAIN/token/refresh",
        "code_challenge_methods_supported": ["plain", "S256"]
      }
    }
  }'`;

Les connexions d'entreprise utilisant [OpenID Connect](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/oidc) ou [Okta Workforce](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta) comme le fournisseur d’identité peut prendre en charge la Proof Key for Code Exchange (PKCE), ainsi que le mappage des attributs et des jetons.

## Configurer la PKCE pour les connexions OIDC

Les connexions <Tooltip href="/docs/fr-ca/glossary?term=openid" tip="OpenID
Norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans avoir à collecter leurs informations de connexion." cta="Voir le glossaire">OpenID</Tooltip> Connect et Okta Workforce sont automatiquement configurées pour prendre en charge la Proof Key for Code Exchange (PKCE).

Si votre fournisseur d’identité OIDC (<Tooltip href="/docs/fr-ca/glossary?term=idp" tip="Fournisseur d’identité (IdP)
Service de stockage et de gestion des identités numériques." cta="Voir le glossaire">IdP</Tooltip>) prend en charge PKCE via les métadonnées de découverte OIDC, Auth0 utilisera automatiquement l’algorithme le plus sécurisé disponible. Pour plus de renseignements sur les métadonnées de découverte OIDC, voir la [documentation d’OpenID](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).

### Afficher la configuration PKCE pour une connexion

Vous pouvez consulter la configuration PKCE pour une connexion spécifique via le <Tooltip href="/docs/fr-ca/glossary?term=auth0-dashboard" tip="Auth0 Dashboard
Principal produit d’Auth0 pour configurer vos services." cta="Voir le glossaire">Auth0 Dashboard</Tooltip> :

1. Naviguez vers **Authentification > Entreprise** et sélectionnez votre fournisseur OIDC (OpenID Connect ou Okta Workforce).
2. Sélectionnez l’onglet **Paramètres**.
3. Dans la section **Général**, localisez le champ **Profil de connexion**.

<Tabs>
  <Tab title="Auth0 Dashboard">
    Vous pouvez gérer la configuration PKCE pour une connexion dans Auth0 Dashboard :

    1. Naviguez jusqu’à [**Dashboard > Authenticate (Authentifier) > Enterprise (Entreprise)**](https://manage.auth0.com/#/connections/enterprise) et sélectionnez votre fournisseur OIDC (OpenID Connect ou Okta Workforce).
    2. Sélectionnez l’onglet **Settings (Paramètres)** et localisez le champ **Connection Profile (Profil de connexion)**.
    3. Définissez la propriété `pkce` sur l’une des [valeurs prises en charge](#supported-pkce-configuration-values) indiquées ci-dessous.
    4. Sélectionnez **Save (Enregistrer)**.
  </Tab>

  <Tab title="Management API">
    #### Utiliser le point de terminaison à des fins de découverte

    <AuthCodeBlock children={codeExample1} language="bash" />

    #### Sans point de terminaison à des fins de découverte

    Sans `discovery_url` , chacun des champs requis de l'objet `oidc_metadata` doit être rempli manuellement.

    <AuthCodeBlock children={codeExample2} language="bash" />
  </Tab>
</Tabs>

### Valeurs de configuration PKCE prises en charge

Auth0 prend en charge les valeurs suivantes pour la configuration PKCE :

| Valeur     | Description                                                                                                                                                                                                                                                     |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `auto`     | Valeur par défaut. Utilise l’algorithme le plus puissant disponible.                                                                                                                                                                                            |
| `s256`     | Utilise l’algorithme SHA-256. Auth0 ne prend pas en charge les jetons RS512 pour l’instant.                                                                                                                                                                     |
| `plain`    | Utilise le texte en clair tel que décrit dans la \[Spécification PKCE]\([https://www.rfc-editor.org/rfc/rfc7636#section-4.2](https://www.rfc-editor.org/rfc/rfc7636#section-4.2) « Proof Key for Code Exchange par OAuth Public Clients - Code Défi-réponse »). |
| `disabled` | Désactive la prise en charge de PKCE.                                                                                                                                                                                                                           |

<Warning>
  Configurer la propriété `pkce` à une valeur autre que `auto` pourrait empêcher le bon fonctionnement d’une connexion si la valeur sélectionnée n’est pas prise en charge par le fournisseur d’identité.

  Ne réglez pas la propriété sur `disabled`, sauf lorsque vous dépannez des problèmes d’authentification.
</Warning>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  **Limitation Microsoft Entra ID**

  Si vous utilisez une connexion OpenID Connect pour Microsoft Entra ID, vous devez définir `pkce` sur `s256` car les métadonnées de la connexion n’exposent pas l’algorithme de hachage utilisé. À ce stade, la [connexion d’entreprise Microsoft Entra ID](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2) ne prend pas en charge PKCE.
</Callout>

## Mapper les demandes pour les connexions OIDC

Les connexions OpenID Connect et Okta Workforce peuvent automatiquement mapper les demandes reçues du fournisseur d’identité (IdP). Vous pouvez configurer ce mappage à l’aide d’un modèle de bibliothèque fourni par Auth0 ou en saisissant directement votre propre modèle.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Les demandes mappées ne sont pas automatiquement ajoutées à un jeton d’ID d’Auth0. Pour ajouter des demandes à un jeton d’ID, voir [Créer des demandes personnalisées](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims#create-custom-claims).
</Callout>

### Propriétés du modèle de mappage

Les modèles de mappage prennent en charge les propriétés de l’objet `options.attribute_map` énumérées ci-dessous. Les modèles doivent être au format JSON avec des paires clé/valeur valides.

| Propriété        | Requis ?   | Description                                                                                                                                                      |
| ---------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `mapping_mode`   | Requis     | Méthode utilisée pour mapper les demandes entrantes.                                                                                                             |
| `userinfo_scope` | Facultatif | Permissions à demander au fournisseur d'identité lors de l'autorisation, qui déterminent les revendications disponibles depuis le point de terminaison UserInfo. |
| `attributes`     | Requis     | Objet contenant les détails de mappage des demandes entrantes.                                                                                                   |

### Mode de mappage

La propriété `mapping_mode` définit la méthode utilisée pour faire correspondre les demandes entrantes de l’IdP au profil utilisateur Auth0. `mapping_mode` prend en charge les valeurs suivantes :

| Value (Valeur) | Description                                              |
| -------------- | -------------------------------------------------------- |
| `use_map`      | Utilise le modèle fourni pour cartographier les données. |
| `bind_all`     | Copie tous les éléments de données fournis par le IdP.   |

#### Demandes restreintes

Certaines demandes sont réservées à l’usage d’Auth0 : de telles demandes ne peuvent pas être utilisées comme clés d’attribut pour les profils utilisateurs.

Si vous attribuez la valeur `bind_all` à la propriété `mapping_mode`, votre IdP peut tenter de faire correspondre des valeurs à une ou plusieurs de ces demandes restreintes. Bien que cela n’empêche pas les utilisateurs de s’authentifier sur votre connexion, les valeurs associées aux demandes restreintes ne sont **pas** transmises au profil utilisateur Auth0.

Si vous attribuez la valeur `use_map` à `mapping_mode`, vous pouvez faire correspondre la demande restreinte entrante à une demande valide :

```lines theme={null}
"attribute_map": {
        "mapping_mode": "use_map",
        "attributes": {
            "amr": "{context.tokenset.amr}" // `amr` is a restricted claim and will not be mapped
            "federated_amr": "{context.tokenset.amr}" // `federated_amr` is not a restricted claim and will be mapped
        }
    }
```

Pour une liste complète des demandes restreintes, consulter [Créer des demandes personnalisées](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims).

### La permission UserInfo

La propriété `userinfo_scope` définit les permissions supplémentaires incluses dans la demande d’autorisation envoyée à l’IdP. Ces permissions déterminent les revendications disponibles depuis le point de terminaison UserInfo de l’IdP. Auth0 appelle ensuite le point de terminaison UserInfo en utilisant le jeton d’accès accordé avec ces permissions.

`userinfo_scope` n’est effectif que lorsque `mapping_mode` est défini sur `use_map`. Par exemple, pour inclure la permission `groups` dans la demande d’autorisation et mapper la revendication résultante au profil utilisateur Auth0 :

```lines theme={null}
"attribute_map": {
    . . .
    "mapping_mode": "use_map",
    "userinfo_scope": "openid email profile groups",
    "attributes": {
        "groups": "${context.userinfo.groups}"
    },
    . . .
}
```

### Attributs

La propriété `attributes` est un objet contenant des informations de mappage qui permettent à Auth0 d’interpréter les demandes entrantes de l’IdP. Les informations de mappage doivent être fournies sous forme de paires clé/valeur.

La clé à gauche correspond à un attribut de profil utilisateur Auth0. La valeur à droite représente la demande entrante de l’IdP qui peut être exprimée comme une valeur littérale, un objet de contexte dynamique ou une combinaison des deux. Les objets de contexte dynamique sont des expressions de modèle écrites dans le format `${variable}` familier.

```lines theme={null}
"attribute_map": {
    . . .
    "attributes": {
        "name": "${context.tokenset.name}",
        "email": "${context.tokenset.email}",
        "username": "${context.tokenset.preferred_username}"
    }
}
```

#### Valeurs littérales

Une valeur littérale est une valeur statique attribuée à un attribut de profil spécifique pour tous les utilisateurs sur votre connexion.

Par exemple, si vous configurez une connexion OIDC SalesForce et que vous souhaitez attribuer le même identifiant de communauté SFDC à tous les profils utilisateurs, vous pouvez procéder comme suit :

```lines theme={null}
"attribute_map": {
    . . .
    "attributes": {
        …
        "sf_community_id": "3423409219032-32"
    }
}
```

#### Objet de contexte

Vous pouvez faire correspondre des valeurs dynamiques aux attributs du profil utilisateur en utilisant l’objet `context`. Cela vous permet de stocker des valeurs uniques pour les profils individuels, contrairement aux valeurs littérales qui sont statiques pour tous les profils.

L’objet `context` prend en charge les propriétés suivantes :

| Propriété            | Description                                                                                                                                                                                                                 |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `context.connection` | Contient les propriétés suivantes :<br /><br /><li> `id` : l’identifiant unique de la connexion (par exemple, `con_4423423423432423`).</li><br /><li> `strategy` : la stratégie de connexion (par exemple, `oidc`).</li>    |
| `context.tokenset`   | Contient les propriétés suivantes :<br /><br /><li> `access_token` : l’intégralité du jeton d’accès validé envoyé par l’IdP.</li><br /><li>`&lt;claim name&gt;` : toute revendication de jeton d’ID envoyée par l’IdP.</li> |
| `context.userinfo`   | Contient les propriétés suivantes :<br /><br /><li> `&lt;claim name&gt;` : toute revendication disponible fournie par le point de terminaison UserInfo de l’IdP.</li>                                                       |

### Exemples

#### Mappage simple des demandes utilisateur

Cet exemple montre comment faire correspondre les demandes utilisateur courantes au profil utilisateur Auth0 avec les données du jeton d’ID :

```lines theme={null}
"attribute_map": {
    . . .
    "attributes": {
        "name": "${context.tokenset.name}",
        "email": "${context.tokenset.email}",
        "username": "${context.tokenset.preferred_username}"
    }
}
```

#### Mappage des demandes de groupe

Cet exemple montre comment faire correspondre les groupes au profil utilisateur Auth0 à partir de l’IdP entrant :

```lines theme={null}
"attribute_map": {
    . . .
    "attributes": {
        "federated_groups": "${context.userinfo.groups}",
        "federated_locale": "${context.userinfo.locale}",
        "federated_zoneinfo": "${context.userinfo.zoneinfo}"
    }
}
```

#### Combinaison de valeurs littérales et d’objets de contexte

Cet exemple montre comment combiner des valeurs littérales et des expressions de modèle dynamique pour faire correspondre une valeur complexe à un attribut sur le profil utilisateur Auth0 :

```lines theme={null}
"attribute_map":{
    . . .
    "attributes": {
        "alt_id": "user_email|${context.tokenset.email}",
        . . .
    }
}
```