Configurer la PKCE et le mappage des demandes pour les connexions OIDC

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

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.

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

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

Auth0 prend en charge les valeurs suivantes pour la configuration 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 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.

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 :

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

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

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

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 :

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

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

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