メインコンテンツへスキップ
OpenID Connect または Okta Workforce を として使用するエンタープライズ接続では、Proof Key for Code Exchange (PKCE) と、属性およびトークンのマッピングをサポートできます。

​
OIDC 接続用に PKCE を設定する

Connect 接続と Okta Workforce 接続は、Proof Key for Code Exchange (PKCE) をサポートするよう自動的に設定されます。 OIDC の IDプロバイダー (IdP) が OIDC Discovery メタデータを介して PKCE をサポートしている場合、Auth0 はデフォルトで使用可能な最も強力なアルゴリズムを使用します。OIDC Discovery メタデータの詳細については、OpenID のドキュメントを参照してください。

​
接続の PKCE 設定を確認する

特定の接続の PKCE 設定は、から確認できます。
  1. Authentication > Enterprise に移動し、OIDC プロバイダー (OpenID Connect または Okta Workforce) を選択します。
  2. Settings タブを選択します。
  3. General セクションで、Connection Profile フィールドを探します。
接続の PKCE 設定は、Auth0 Dashboard で管理できます。
  1. Dashboard > Authenticate >Enterprise に移動し、OIDC プロバイダー (OpenID Connect または Okta Workforce) を選択します。
  2. Settings タブを選択し、Connection Profile フィールドを探します。
  3. pkce プロパティを、以下に示すサポートされている値のいずれかに設定します。
  4. Save を選択します。

​
サポートされる PKCE 設定値

Auth0 では、PKCE 設定として次の値をサポートしています。
ValueDescription
autoデフォルト値です。利用可能な中で最も強力なアルゴリズムを使用します。
s256SHA-256 アルゴリズムを使用します。Auth0 は現在、RS512 トークンをサポートしていません。
plainPKCE 仕様 に記載されているとおり、平文を使用します。
disabledPKCE サポートを無効にします。
pkce プロパティを auto 以外の値に設定すると、選択した値が IDプロバイダーでサポートされていない場合、接続が正しく動作しない可能性があります。認証の問題をトラブルシューティングする場合を除き、このプロパティを disabled に設定しないでください。
Microsoft Entra ID の制限事項Microsoft Entra ID の OpenID Connect 接続を使用している場合は、接続のメタデータで使用されているハッシュ アルゴリズムが公開されないため、pkce を s256 に設定する必要があります。現在、Microsoft Entra ID エンタープライズ接続 は PKCE をサポートしていません。

​
OIDC 接続のクレームをマッピングする

OpenID Connect 接続および Okta Workforce 接続では、IDプロバイダー (IdP) から受け取ったクレームを自動的にマッピングできます。このマッピングは、Auth0 が提供するライブラリテンプレートを使用して設定することも、独自のテンプレートを直接入力して設定することもできます。
マッピングされたクレームは、Auth0 の IDトークンに自動的には追加されません。IDトークンにクレームを追加するには、カスタムクレームを作成するを参照してください。

​
マッピングテンプレートのプロパティ

マッピングテンプレートでは、以下の options.attribute_map オブジェクトのプロパティをサポートしています。テンプレートは、有効なキーと値のペアを含む JSON 形式である必要があります。
プロパティ必須説明
mapping_mode必須受信クレームのマッピングに使用する方法。
userinfo_scope任意認可時に IdP に要求するスコープ。これによって、UserInfo エンドポイントで利用可能なクレームが決まります。
attributes必須受信クレームのマッピングの詳細を含むオブジェクト。

​
マッピングモード

mapping_mode プロパティは、IdP から受信したクレームを Auth0 のユーザープロファイルにマッピングする際の方法を定義します。mapping_mode では、次の値をサポートしています。
値説明
use_map指定したテンプレートを使用してデータをマッピングします。
bind_allIdP から提供されたすべてのデータ要素をコピーします。

​
制限付きクレーム

一部のクレームは Auth0 専用として予約されているため、ユーザープロファイルの属性キーとしては使用できません。 mapping_mode プロパティを bind_all に設定すると、IdP がこれらの制限付きクレームの1つ以上に値をマッピングしようとすることがあります。これによってその接続でユーザーが認証できなくなることはありませんが、制限付きクレームに関連付けられた値は Auth0 のユーザープロファイルにマッピングされません。 mapping_mode を use_map に設定すると、受信した制限付きクレームを有効なクレームにマッピングできます。 
"attribute_map": {
        "mapping_mode": "use_map",
        "attributes": {
            "amr": "{context.tokenset.amr}", // `amr` は制限付きクレームのため、マッピングされません
            "federated_amr": "{context.tokenset.amr}" // `federated_amr` は制限付きクレームではないため、マッピングされます
        }
    }
制限付きクレームの一覧については、Create Custom Claimsを参照してください。

​
UserInfo スコープ

userinfo_scope プロパティは、Auth0 が IdP への認可リクエストに含めるスコープを定義します。これらのスコープは、IdP が UserInfo エンドポイントから提供するクレームを決定します。属性マップが context.userinfo properties を参照している場合、Auth0 はこれらのスコープで付与されたアクセストークンを使用して、IdP の UserInfo エンドポイントを呼び出します。 たとえば、標準の OIDC スコープと groups スコープをリクエストして、UserInfo エンドポイントからグループクレームを取得できるようにするには、次のように設定します。 
"attribute_map": {
    "mapping_mode": "use_map",
    "userinfo_scope": "openid email profile groups",
    "attributes": {
        "name": "${context.tokenset.name}",
        "groups": "${context.userinfo.groups}"
    }
}

​
属性

attributes プロパティは、Auth0 が IdP から受信したクレームを解釈できるようにするためのマッピング情報を含むオブジェクトです。マッピング情報はキーと値のペアで指定する必要があります。 左側のキーは Auth0 のユーザープロファイル属性に対応します。右側の値は IdP から受信したクレームを表し、リテラル値、動的コンテキストオブジェクト、またはその組み合わせで指定できます。動的コンテキストオブジェクトは、${variable} 形式のテンプレート式です。 
"attribute_map": {
    . . .
    "attributes": {
        "name": "${context.tokenset.name}",
        "email": "${context.tokenset.email}",
        "username": "${context.tokenset.preferred_username}"
    }
}

​
リテラル値

リテラル値とは、接続内のすべてのユーザーについて、特定のプロファイル属性にマッピングされる固定値です。 たとえば、SalesForce OIDC 接続を設定していて、すべてのユーザープロファイルに同じ SFDC Community ID を割り当てる場合は、次のように設定できます。 
"attribute_map": {
    . . .
    "attributes": {
        …
        "sf_community_id": "3423409219032-32"
    }
}

​
context オブジェクト

context オブジェクトを使用すると、動的な値をユーザープロファイル属性にマッピングできます。これにより、すべてのプロファイルで共通の固定値ではなく、各プロファイルに固有の値を保存できます。 context オブジェクトでは、次のプロパティをサポートしています。
PropertyDescription
context.connection次のプロパティが含まれます。

  • id: 接続の一意の識別子 (例: con_4423423423432423) 。

  • strategy: 接続のストラテジー (例: oidc) 。
    • context.tokenset次のプロパティが含まれます。

  • access_token: IdP から送信された、検証済みのアクセストークン全体。

  • <claim name>: IdP から送信された任意の IDトークンのクレーム。
    • context.userinfo次のプロパティが含まれます。

  • <claim name>: IdP の UserInfo エンドポイントから提供される利用可能な任意のクレーム。

    • ​
    例

    ​
    シンプルなユーザークレームのマッピング

    この例では、 のデータを使って、一般的なユーザークレームをAuth0のユーザープロファイルにマッピングする方法を示します。 
    "attribute_map": {
    . . .
    "attributes": {
        "name": "${context.tokenset.name}",
        "email": "${context.tokenset.email}",
        "username": "${context.tokenset.preferred_username}"
    }
}

    ​
    グループクレームのマッピング

    この例では、IdPから渡されるグループをAuth0のユーザープロファイルにマッピングする方法を示します。 
    "attribute_map": {
    . . .
    "attributes": {
        "federated_groups": "${context.userinfo.groups}",
        "federated_locale": "${context.userinfo.locale}",
        "federated_zoneinfo": "${context.userinfo.zoneinfo}"
    }
}

    ​
    リテラル値とコンテキストオブジェクトを組み合わせる

    この例では、リテラル値と動的なテンプレート式を組み合わせて、複雑な値を Auth0 ユーザープロファイルの属性にマッピングする方法を示します。 
    "attribute_map":{
    . . .
    "attributes": {
        "alt_id": "user_email|${context.tokenset.email}",
        . . .
    }
}