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.

Les connexions d’entreprise utilisant OpenID Connect ou Okta Workforce 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 OpenID 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 (IdP) 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.

​

Afficher la configuration PKCE pour une connexion

Vous pouvez consulter la configuration PKCE pour une connexion spécifique via le Auth0 Dashboard :

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.

Auth0 Dashboard

Vous pouvez gérer la configuration PKCE pour une connexion dans Auth0 Dashboard :

1. Naviguez jusqu’à Dashboard > Authenticate (Authentifier) > Enterprise (Entreprise) 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 indiquées ci-dessous.
4. Sélectionnez Save (Enregistrer).

​

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 « Proof Key for Code Exchange par OAuth Public Clients - Code Défi-réponse »).
disabled	Désactive la prise en charge de PKCE.

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.

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 ne prend pas en charge PKCE.

​

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.

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.

​

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 pour envoyer au point de terminaison IdP 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 :

"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.

​

La permission UserInfo

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 :

"attribute_map": {
    . . .
    "mapping_mode": "bind_all",
    "userinfo_scope": "openid email profile 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.

"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 :

"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 : id : l’identifiant unique de la connexion (par exemple, con_4423423423432423). strategy : la stratégie de connexion (par exemple, oidc).
context.tokenset	Contient les propriétés suivantes : access_token : l’intégralité du jeton d’accès validé envoyé par l’IdP. <claim name> : toute revendication de jeton d’ID 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 demandes utilisateur

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

"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 :

"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 :

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