> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/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 [processedChildren, setProcessedChildren] = useState(children);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      unsubscribe = window.autorun(() => {
        let processedChildren = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          processedChildren = processedChildren.replace(new RegExp(key, "g"), value);
        }
        setProcessedChildren(processedChildren);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  return <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
      {processedChildren}
    </CodeBlock>;
};

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/fr-ca/authenticate/identity-providers/enterprise-identity-providers/oidc) ou [Okta Workforce](/docs/fr-CA/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.

<div id="configure-pkce-for-oidc-connections">
  ## Configurer la PKCE pour les connexions OIDC
</div>

Les connexions <Tooltip href="/docs/fr-CA/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/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).

<div id="view-pkce-configuration-for-a-connection">
  ### Afficher la configuration PKCE pour une connexion
</div>

Vous pouvez consulter la configuration PKCE pour une connexion spécifique via le <Tooltip href="/docs/fr-CA/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>

<div id="supported-pkce-configuration-values">
  ### Valeurs de configuration PKCE prises en charge
</div>

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

<table class="table">
  <thead>
    <tr>
      <th>Valeur</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`auto`</td>
      <td>Valeur par défaut. Utilise l’algorithme le plus puissant disponible.</td>
    </tr>

    <tr>
      <td>`s256`</td>
      <td>Utilise l’algorithme SHA-256. Auth0 ne prend pas en charge les jetons RS512 pour l’instant.</td>
    </tr>

    <tr>
      <td>`plain`</td>
      <td>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 »).</td>
    </tr>

    <tr>
      <td>`disabled`</td>
      <td>Désactive la prise en charge de PKCE.</td>
    </tr>
  </tbody>
</table>

<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 Azure AD**

  Si vous utilisez une connexion OpenID Connect pour Azure AD, 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 Azure AD](/docs/fr-CA/fr-ca/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2) ne prend pas en charge PKCE.
</Callout>

<div id="map-claims-for-oidc-connections">
  ## Mapper les demandes pour les connexions OIDC
</div>

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/fr-ca/secure/tokens/json-web-tokens/create-custom-claims#create-custom-claims).
</Callout>

<div id="mapping-template-properties">
  ### Propriétés du modèle de mappage
</div>

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.

<table class="table">
  <thead>
    <tr>
      <th><strong>Propriété</strong></th>
      <th><strong>Requis ?</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`mapping_mode`</td>
      <td>Requis</td>
      <td>Méthode utilisée pour mapper les demandes entrantes.</td>
    </tr>

    <tr>
      <td>`userinfo_scope`</td>
      <td>Facultatif</td>
      <td>Permissions pour envoyer au point de terminaison IdP Userinfo.</td>
    </tr>

    <tr>
      <td>`attributes`</td>
      <td>Requis</td>
      <td>Objet contenant les détails de mappage des demandes entrantes.</td>
    </tr>
  </tbody>
</table>

<div id="mapping-mode">
  ### Mode de mappage
</div>

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 :

<table class="table">
  <thead>
    <tr>
      <th><strong>Value (Valeur)</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`use_map`</td>
      <td>Utilise le modèle fourni pour cartographier les données.</td>
    </tr>

    <tr>
      <td>`bind_all`</td>
      <td>Copie tous les éléments de données fournis par le IdP.</td>
    </tr>
  </tbody>
</table>

<div id="restricted-claims">
  #### Demandes restreintes
</div>

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/fr-ca/secure/tokens/json-web-tokens/create-custom-claims).

<div id="userinfo-scope">
  ### La permission UserInfo
</div>

La propriété `userinfo_scope` définit les permissions qu’Auth0 envoie au point de terminaison UserInfo de l’IdP lorsqu’elles sont demandées.

Par exemple, si vous souhaitez envoyer les permissions OIDC standard et la permission `groups` lorsque vous demandez le point de terminaison UserInfo, vous pouvez procéder comme suit :

```lines theme={null}
"attribute_map": {
    . . .
    "mapping_mode": "bind_all",
    "userinfo_scope": "openid email profile groups",
    . . .
}
```

<div id="attributes">
  ### Attributs
</div>

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}"
    }
}
```

<div id="literal-values">
  #### Valeurs littérales
</div>

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"
    }
}
```

<div id="context-object">
  #### Objet de contexte
</div>

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 :

<table class="table">
  <thead>
    <tr>
      <th>Propriété</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`context.connection`</td>
      <td>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></td>
    </tr>

    <tr>
      <td>`context.tokenset`</td>
      <td>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></td>
    </tr>

    <tr>
      <td>`context.userinfo`</td>
      <td>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></td>
    </tr>
  </tbody>
</table>

<div id="examples">
  ### Exemples
</div>

<div id="simple-user-claim-mapping">
  #### Mappage simple des demandes utilisateur
</div>

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}"
    }
}
```

<div id="group-claim-mapping">
  #### Mappage des demandes de groupe
</div>

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}"
    }
}
```

<div id="combining-literal-values-and-context-objects">
  #### Combinaison de valeurs littérales et d’objets de contexte
</div>

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}",
        . . .
    }
}
```