Configurer PKCE et le mappage des revendications pour les connexions OIDC

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

Les connexions d’entreprise qui utilisent OpenID Connect ou Okta Workforce comme fournisseur d’identité peuvent prendre en charge Proof Key for Code Exchange (PKCE), ainsi que le mappage des attributs et des jetons.

​

Configurer PKCE pour les connexions OIDC

Les connexions OpenID Connect et Okta Workforce sont automatiquement configurées pour prendre en charge Proof Key for Code Exchange (PKCE).

Si votre fournisseur d’identité OIDC (IdP) prend en charge PKCE au moyen des métadonnées de découverte OIDC, Auth0 utilisera par défaut l’algorithme le plus robuste disponible. Pour en savoir plus sur les métadonnées de découverte OIDC, consultez la documentation d’OpenID.

​

Consulter la configuration PKCE d’une connexion

Vous pouvez consulter la configuration PKCE d’une connexion donnée dans le Auth0 Dashboard :

1. Accédez à Authentication > Enterprise et choisissez votre fournisseur OIDC (OpenID Connect ou Okta Workforce).
2. Sélectionnez l’onglet Settings.
3. Dans la section General, repérez le champ Connection Profile.

Auth0 Dashboard

Vous pouvez gérer la configuration PKCE d’une connexion à partir de l’Auth0 Dashboard :

1. Accédez à Dashboard > Authenticate >Enterprise et choisissez votre fournisseur OIDC (OpenID Connect ou Okta Workforce).
2. Sélectionnez l’onglet Settings et repérez le champ Connection Profile.
3. Définissez la propriété pkce sur l’une des valeurs prises en charge ci-dessous.
4. Sélectionnez Save.

Management API

​

Utiliser le point de terminaison de découverte

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

​

Sans point de terminaison de découverte

Sans discovery_url, l’objet oidc_metadata doit être rempli manuellement avec les champs nécessaires.

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"]
      }
    }
  };

​

Valeurs de configuration PKCE prises en charge

Auth0 prend en charge les valeurs de configuration PKCE suivantes :

Valeur	Description
auto	Valeur par défaut. Utilise l’algorithme le plus robuste disponible.
s256	Utilise l’algorithme SHA-256. Auth0 ne prend actuellement pas en charge les jetons RS512.
plain	Utilise le texte en clair, comme décrit dans la spécification PKCE.
disabled	Désactive la prise en charge de PKCE.

Définir la propriété pkce à une valeur autre que auto peut empêcher une connexion de fonctionner correctement si cette valeur n’est pas prise en charge par le fournisseur d’identité.

Ne définissez pas la propriété à disabled, sauf pour résoudre des problèmes d’authentification.

Limitation de Microsoft Entra ID

Si vous utilisez une connexion OpenID Connect pour Microsoft Entra ID, vous devez définir pkce à s256, car les métadonnées de la connexion n’exposent pas l’algorithme de hachage utilisé. À l’heure actuelle, la connexion d’entreprise Microsoft Entra ID ne prend pas en charge PKCE.

​

Mapper les revendications pour les connexions OIDC

Les connexions OpenID Connect et Okta Workforce peuvent mapper automatiquement les revendications 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.

Les revendications mappées ne sont pas automatiquement ajoutées à un jeton d’identité d’Auth0. Pour ajouter des revendications à un jeton d’identité, consultez Créer des revendications personnalisées.

​

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 ci-dessous. Les modèles doivent être au format JSON et contenir des paires clé-valeur valides.

Propriété	Obligatoire ?	Description
mapping_mode	Obligatoire	Méthode utilisée pour faire correspondre les revendications entrantes.
userinfo_scope	Facultatif	Scopes à demander à l’IdP pendant l’autorisation, qui déterminent quelles revendications sont disponibles à partir du point de terminaison UserInfo.
attributes	Obligatoire	Objet contenant les détails de mappage des revendications entrantes.

​

Mode de mappage

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

Valeur	Description
use_map	Utilise le modèle fourni pour faire correspondre les données.
bind_all	Copie tous les éléments de données fournis par l’IdP.

​

Claims restreints

Certaines revendications sont réservées à l’usage d’Auth0; elles ne peuvent donc pas servir de clés d’attribut pour les profils utilisateur.

Si vous définissez la propriété mapping_mode sur bind_all, votre IdP peut tenter d’associer des valeurs à une ou plusieurs de ces revendications restreintes. Bien que cela n’empêche pas les utilisateurs de s’authentifier sur votre connexion, les valeurs associées à des revendications restreintes ne sont pas ajoutées au profil utilisateur Auth0.

Si vous définissez mapping_mode sur use_map, vous pouvez mapper la revendication restreinte entrante vers une revendication valide :

"attribute_map": {
        "mapping_mode": "use_map",
        "attributes": {
            "amr": "{context.tokenset.amr}", // `amr` est une revendication restreinte et ne sera pas mappée
            "federated_amr": "{context.tokenset.amr}" // `federated_amr` n'est pas une revendication restreinte et sera mappée
        }
    }

Pour obtenir la liste complète des revendications restreintes, consultez Create Custom Claims.

​

Scope UserInfo

La propriété userinfo_scope définit les scopes qu’Auth0 inclut dans la demande d’autorisation auprès de l’IdP. Ces scopes déterminent quelles revendications l’IdP rend disponibles à partir de son point de terminaison UserInfo. Lorsque le mappage d’attributs fait référence aux propriétés context.userinfo, Auth0 appelle le point de terminaison UserInfo de l’IdP à l’aide du jeton d’accès accordé avec ces scopes.

Par exemple, si vous voulez demander les scopes OIDC standard ainsi que le scope groups pour que les revendications de groupe soient disponibles à partir du point de terminaison UserInfo, vous pouvez le configurer comme suit :

"attribute_map": {
    "mapping_mode": "use_map",
    "userinfo_scope": "openid email profile groups",
    "attributes": {
        "name": "${context.tokenset.name}",
        "groups": "${context.userinfo.groups}"
    }
}

​

Attributs

La propriété attributes est un objet qui contient les informations de correspondance permettant à Auth0 d’interpréter les revendications entrantes de l’IdP. Ces informations doivent être fournies sous forme de paires clé-valeur.

La clé de gauche correspond à un attribut du profil d’utilisateur Auth0. La valeur de droite représente la revendication entrante de l’IdP, qui peut prendre la forme d’une valeur littérale, d’un objet de contexte dynamique ou d’une combinaison des deux. Les objets de contexte dynamique sont des expressions de modèle écrites au format familier ${variable}.

"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 associée à un attribut de profil précis pour tous les utilisateurs de votre connexion.

Par exemple, si vous configurez une connexion OIDC Salesforce et souhaitez attribuer le même ID de communauté SFDC à tous les profils utilisateur, vous pouvez le faire comme suit :

"attribute_map": {
    . . .
    "attributes": {
        …
        "sf_community_id": "3423409219032-32"
    }
}

​

Objet context

Vous pouvez associer des valeurs dynamiques aux attributs du profil de l’utilisateur au moyen de l’objet context. Cela vous permet de stocker des valeurs uniques pour des profils individuels, par opposition à des valeurs littérales 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 : id : L’identifiant unique de la connexion (par exemple, con_4423423423432423). strategy : La stratégie de la connexion (par exemple, oidc).
context.tokenset	Contient les propriétés suivantes : access_token : Le jeton d’accès validé complet envoyé par l’IdP. <claim name> : Toute revendication du jeton d’identité envoyée par l’IdP.
context.userinfo	Contient les propriétés suivantes : <claim name> : Toute revendication disponible fournie par le point de terminaison UserInfo de l’IdP.

​

Exemples

​

Mappage simple des revendications d’utilisateur

Cet exemple montre comment faire correspondre des revendications d’utilisateur courantes au profil utilisateur Auth0 à partir des données du jeton d’identité:

"attribute_map": {
    . . .
    "attributes": {
        "name": "${context.tokenset.name}",
        "email": "${context.tokenset.email}",
        "username": "${context.tokenset.preferred_username}"
    }
}

​

Mappage de la revendication de groupe

Cet exemple montre comment mapper des groupes provenant du fournisseur d’identité (IdP) entrant vers le profil utilisateur Auth0 :

"attribute_map": {
    . . .
    "attributes": {
        "federated_groups": "${context.userinfo.groups}",
        "federated_locale": "${context.userinfo.locale}",
        "federated_zoneinfo": "${context.userinfo.zoneinfo}"
    }
}

​

Combiner des valeurs littérales et des objets de contexte

Cet exemple montre comment combiner des valeurs littérales et des expressions de gabarit dynamiques pour associer une valeur complexe à un attribut du profil utilisateur Auth0 :

"attribute_map":{
    . . .
    "attributes": {
        "alt_id": "user_email|${context.tokenset.email}",
        . . .
    }
}