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.
Les connexions 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 () 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.
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 ADSi 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.
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.
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.
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.
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 :
Report incorrect code
Copy
Ask AI
"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 } }
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 :
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.
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 :
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.
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 :
