Configurer PKCE et le mappage des claims pour les connexions OIDC

Configurer la clé de preuve pour l’échange de code (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 la clé de preuve pour l’échange de code (PKCE), ainsi que le mappage des attributs et des tokens.

​

Configurer PKCE pour les connexions OIDC

OpenID Connect et les connexions Okta Workforce sont automatiquement configurées pour prendre en charge la clé de preuve pour l’échange de code (PKCE).

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

​

Afficher la configuration PKCE d’une connexion

Vous pouvez afficher la configuration PKCE d’une connexion précise 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 dans 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. Réglez 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 suivantes pour la configuration PKCE :

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 du 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 sur une valeur autre que auto peut empêcher une connexion de fonctionner correctement si la valeur sélectionnée n’est pas prise en charge par le fournisseur d’identité.

Ne définissez pas la propriété sur disabled, sauf pour le dépannage de 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 sur s256, car les métadonnées de la connexion n’indiquent pas l’algorithme de hachage utilisé. À l’heure actuelle, la connexion Enterprise Microsoft Entra ID ne prend pas en charge PKCE.

​

Mapper les claims pour les connexions OIDC

Les connexions OpenID Connect et Okta Workforce peuvent mapper automatiquement les claims reçus 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 claims mappés ne sont pas automatiquement ajoutés à un ID token d’Auth0. Pour ajouter des claims à un ID token, consultez Créer des claims personnalisés.

​

Propriétés des modèles 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 mapper les claims entrants.
userinfo_scope	Facultatif	Scopes à demander à l’IdP au moment de l’autorisation, qui déterminent quels claims sont disponibles à partir du point de terminaison UserInfo.
attributes	Obligatoire	Objet contenant les détails du mappage pour les claims entrants.

​

Mode de mappage

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

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

​

Claims restreints

Certains claims sont réservés à Auth0; ils ne peuvent donc pas être utilisés comme clés d’attribut pour les profils utilisateur.

Si vous définissez la propriété mapping_mode sur bind_all, votre IdP peut tenter de mapper des valeurs à un ou plusieurs de ces claims restreints. Bien que cela n’empêche pas les utilisateurs de s’authentifier avec votre connexion, les valeurs associées aux claims restreints ne sont pas mappées au profil utilisateur Auth0.

Si vous définissez mapping_mode sur use_map, vous pouvez mapper le claim restreint entrant vers un claim 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 claims réservés, consultez Créer des claims personnalisés.

​

Scope UserInfo

La propriété userinfo_scope définit les scopes qu’Auth0 inclut dans la demande d’autorisation envoyée à l’IdP. Ces scopes déterminent quelles claims l’IdP rend disponibles depuis son endpoint UserInfo. Lorsque le mappage d’attributs fait référence à context.userinfo properties, Auth0 appelle l’endpoint UserInfo de l’IdP à l’aide du jeton d’accès obtenu avec ces scopes.

Par exemple, si vous voulez demander les scopes OIDC standard ainsi que le scope groups afin que les claims de groupe soient disponibles depuis l’endpoint 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}"
    }
}

​

Attributes

La propriété attributes est un objet qui contient des informations de mappage permettant à Auth0 d’interpréter les claims entrants de l’IdP. Les informations de mappage doivent être fournies sous forme de paires clé-valeur.

La clé de gauche correspond à un attribut du profil utilisateur Auth0. La valeur de droite représente le claim entrant 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 dynamiques sont des expressions de gabarit écrites dans le format bien connu ${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 SFDC Community à tous les profils utilisateur, vous pouvez le faire comme suit :

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

​

Objet de contexte

Vous pouvez mapper des valeurs dynamiques à des attributs du profil utilisateur à l’aide de l’objet context. Cela vous permet de stocker des valeurs uniques pour chaque profil, par opposition à des valeurs littérales qui sont identiques 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> : tout claim du ID token envoyé par l’IdP.
context.userinfo	Contient les propriétés suivantes : <claim name> : tout claim disponible fourni par le point de terminaison UserInfo de l’IdP.

​

Exemples

​

Mappage simple des claims utilisateur

Cet exemple montre comment mapper des claims utilisateur courants au profil utilisateur Auth0 à partir des données de l’ID token :

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

​

Mappage des claims de groupe

Cet exemple montre comment mapper les groupes de l’IdP entrant au 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 afin de mapper une valeur complexe à un attribut du profil utilisateur Auth0 :

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