> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. > Configure Proof Key for Code Exchange (PKCE) and mapping templates for OpenID Connect and Okta Workforce connections. # Configure PKCE and Claim Mapping for OIDC Connections Enterprise connections using [OpenID Connect](/docs/authenticate/identity-providers/enterprise-identity-providers/oidc) or O[kta Workforce](/docs/authenticate/identity-providers/enterprise-identity-providers/okta) as the identity provider can support Proof Key for Code Exchange (PKCE), as well as attribute and token mapping. ## Configure PKCE for OIDC connections OpenID Connect and Okta Workforce connections are automatically configured to support Proof Key for Code Exchange (PKCE). If your OIDC identity provider (IdP) supports PKCE through OIDC Discovery metadata, Auth0 will use the strongest algorithm available by default. For more information on OIDC Discovery metadata, review [OpenID’s documentation](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). ### View PKCE configuration for a connection You can view the PKCE configuration for a specific connection through the Auth0 Dashboard: 1. Navigate to **Authentication > Enterprise** and choose your OIDC provider (either OpenID Connect or Okta Workforce). 2. Select the **Settings** tab. 3. In the **General** section, locate the **Connection Profile** field. You can manage the PKCE configuration for a connection through the Auth0 Dashboard: 1. Navigate to [**Dashboard > Authenticate >Enterprise**](https://manage.auth0.com/#/connections/enterprise) and choose your OIDC provider (either OpenID Connect or Okta Workforce). 2. Select the **Settings** tab and locate the **Connection Profile** field. 3. Set the `pkce` property to one of the [supported values](#supported-pkce-configuration-values) listed below. 4. Select **Save**. #### Use discovery endpoint ```bash theme={null} 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" } } }; ``` #### Without discovery endpoint Without a `discovery_url` the `oidc_metadata` object needs to be populated manually with the necessary fields. ```bash theme={null} 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"] } } }; ``` ### Supported PKCE configuration values Auth0 supports the following values for PKCE configuration: | Value | Description | | ---------- | ------------------------------------------------------------------------------------------------------------ | | `auto` | Default value. Uses the strongest algorithm available. | | `s256` | Uses the SHA-256 algorithm. Auth0 does not currently support RS512 tokens. | | `plain` | Uses plaintext as described in the [PKCE specification](https://www.rfc-editor.org/rfc/rfc7636#section-4.2). | | `disabled` | Disables support for PKCE. | Setting the `pkce` property to a value other than `auto`may prevent a connection from working properly if the selected value is not supported by the identity provider. Do not set the property to `disabled` except when troubleshooting authentication issues. **Microsoft Entra ID Limitation** If you are using an OpenID Connect connection for Microsoft Entra ID, you must set `pkce` to `s256` as the connection's metadata does not expose the hashing algorithm used. Currently, the [Microsoft Entra ID Enterprise connection](/docs/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2) does not support PKCE. ## Map Claims for OIDC connections OpenID Connect and Okta Workforce connections can automatically map claims received from the identity provider (IdP). You can configure this mapping through a library template provided by Auth0 or by entering your own template directly. Mapped claims are not automatically added to an Auth0 ID token. To add claims to an ID token, see [Create custom claims](/docs/secure/tokens/json-web-tokens/create-custom-claims#create-custom-claims). ### Mapping template properties Mapping templates support the `options.attribute_map` object properties listed below. Templates must be in JSON format with valid key/value pairs. | Property | Required? | Description | | ---------------- | --------- | -------------------------------------------------------------------------------------------------------------------------- | | `mapping_mode` | Required | Method used to map incoming claims. | | `userinfo_scope` | Optional | Scopes to request from the IdP during authorization, which determine what claims are available from the UserInfo endpoint. | | `attributes` | Required | Object containing mapping details for incoming claims. | ### Mapping mode The `mapping_mode` property defines the method used to map incoming claims from the IdP to the Auth0 user profile. `mapping_mode` supports the following values: | Value | Description | | ---------- | --------------------------------------------- | | `use_map` | Uses the provided template to map the data. | | `bind_all` | Copies all data elements provided by the IdP. | #### Restricted claims Some claims are reserved for use by Auth0; such claims cannot be used as attribute keys for user profiles. If you set the `mapping_mode` property to `bind_all`, your IdP may attempt to map values to one or more of these restricted claims. While this does not prevent users from authenticating on your connection, values associated with restricted claims are **not** mapped to the Auth0 user profile. If you set `mapping_mode` to `use_map`, you can map the incoming restricted claim to a valid one: ```json lines theme={null} "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     } } ``` For a complete list of restricted claims, review [Create Custom Claims](/docs/secure/tokens/json-web-tokens/create-custom-claims). ### UserInfo scope The `userinfo_scope` property defines the scopes that Auth0 includes in the authorization request to the IdP. These scopes determine what claims the IdP makes available from its `UserInfo` endpoint. When the attribute map references `context.userinfo properties`, Auth0 calls the IdP’s `UserInfo` endpoint using the access token granted with these scopes. For example, if you want to request the standard OIDC scopes and the `groups` scope so that group claims are available from the `UserInfo` endpoint, you can configure it as follows: ```json lines theme={null} "attribute_map": { "mapping_mode": "use_map", "userinfo_scope": "openid email profile groups", "attributes": { "name": "${context.tokenset.name}", "groups": "${context.userinfo.groups}" } } ``` ### Attributes The `attributes` property is an object containing mapping information that allows Auth0 to interpret incoming claims from the IdP. Mapping information must be provided as key/value pairs. The key to the left corresponds to an Auth0 user profile attribute. The value to the right represents the incoming claim from the IdP, which can be expressed as a literal value, a dynamic context object, or a combination of both. Dynamic context objects are template expressions written in the familiar `${variable}` format. ```json lines theme={null} "attribute_map": { . . . "attributes": { "name": "${context.tokenset.name}", "email": "${context.tokenset.email}", "username": "${context.tokenset.preferred_username}" } } ``` #### Literal values A literal value is a static value mapped to a specific profile attribute for all users on your connection. For example, if you are configuring a SalesForce OIDC connection and want to assign the same SFDC Community ID to all user profiles, you can do so as follows: ```json lines theme={null} "attribute_map": { . . . "attributes": { … "sf_community_id": "3423409219032-32" } } ``` #### Context object You can map dynamic values to user profile attributes by using the `context` object. This allows you to store unique values for individual profiles, as opposed to literal values that are static across all profiles. The `context` object supports the following properties: | Property | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `context.connection` | Contains the following properties:

  • `id`: The connection’s unique identifier (for example, `con_4423423423432423`).

  • `strategy`: The connection’s strategy (for example, `oidc`).
    • | | `context.tokenset` | Contains the following properties:

  • `access_token`: The entire validated access token sent by the IdP.

  • ``: Any ID token claim sent by the IdP.
    • | | `context.userinfo` | Contains the following properties:

  • ``: Any available claim provided by the IdP’s UserInfo endpoint.
    • | ### Examples #### Simple user claim mapping This example demonstrates how to map common user claims to the Auth0 user profile with data from the ID token: ```json lines theme={null} "attribute_map": { . . . "attributes": { "name": "${context.tokenset.name}", "email": "${context.tokenset.email}", "username": "${context.tokenset.preferred_username}" } } ``` #### Group claim mapping This example shows how to map groups to the Auth0 user profile from the incoming IdP: ```json lines theme={null} "attribute_map": { . . . "attributes": { "federated_groups": "${context.userinfo.groups}", "federated_locale": "${context.userinfo.locale}", "federated_zoneinfo": "${context.userinfo.zoneinfo}" } } ``` #### Combining literal values and context objects This example demonstrates how to combine literal values and dynamic template expressions to map a complex value to an attribute on the Auth0 user profile: ```json lines theme={null} "attribute_map":{ . . . "attributes": { "alt_id": "user_email|${context.tokenset.email}", . . . } } ```