OIDC 接続の PKCE とクレームマッピングを設定する

OpenID Connect および Okta Workforce 接続向けの Proof Key for Code Exchange (PKCE) とマッピングテンプレートを設定します。

OpenID Connect または Okta Workforce をアイデンティティプロバイダーとして使用するエンタープライズ接続では、Proof Key for Code Exchange (PKCE) に加え、属性とトークンのマッピングもサポートできます。

​

OIDC 接続の PKCE を設定する

OpenID Connect と Okta Workforce の接続は、Proof Key for Code Exchange (PKCE) をサポートするよう自動的に設定されています。

OIDC アイデンティティプロバイダー (IdP) が OIDC ディスカバリー メタデータを通じて PKCE をサポートしている場合、Auth0 はデフォルトで利用可能な中で最も強力なアルゴリズムを使用します。OIDC ディスカバリー メタデータの詳細については、OpenID のドキュメントを参照してください。

​

接続のPKCE設定を表示する

特定の接続のPKCE設定は、Auth0 Dashboardで確認できます。

1. Authentication > Enterprise に移動し、OIDCプロバイダー (OpenID Connect または Okta Workforce) を選択します。
2. Settings タブを選択します。
3. General セクションで、Connection Profile フィールドを探します。

Auth0 Dashboard

接続のPKCE設定は、Auth0 Dashboard で管理できます。

1. Dashboard > Authenticate >Enterprise に移動し、OIDCプロバイダー (OpenID Connect または Okta Workforce) を選択します。
2. Settings タブを選択し、Connection Profile フィールドを探します。
3. pkce プロパティを、以下に記載されているサポートされている値のいずれかに設定します。
4. Save を選択します。

Management API

​

discovery endpoint を使用する

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

​

discovery endpoint を使用しない場合

discovery_url がない場合は、oidc_metadata オブジェクトに必要なフィールドを手動で設定する必要があります。

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

​

サポートされている PKCE の設定値

Auth0 では、PKCE の設定に次の値をサポートしています。

値	説明
auto	デフォルト値です。利用可能な中で最も強力なアルゴリズムを使用します。
s256	SHA-256 アルゴリズムを使用します。Auth0 は現在、RS512 トークンをサポートしていません。
plain	PKCE specification に記載されているプレーンテキストを使用します。
disabled	PKCE のサポートを無効にします。

pkce プロパティに auto 以外の値を設定すると、選択した値がアイデンティティプロバイダーでサポートされていない場合、接続が正しく機能しない可能性があります。

認証の問題をトラブルシューティングする場合を除き、このプロパティを disabled に設定しないでください。

Microsoft Entra ID の制限事項

Microsoft Entra ID 用の OpenID Connect 接続を使用している場合、接続のメタデータでは使用されているハッシュアルゴリズムが公開されないため、pkce を s256 に設定する必要があります。現在、Microsoft Entra ID エンタープライズ接続 は PKCE をサポートしていません。

​

OIDC 接続のクレームのマッピング

OpenID Connect 接続と Okta Workforce 接続では、アイデンティティプロバイダー (IdP) から受け取ったクレームを自動的にマッピングできます。このマッピングは、Auth0 が提供するライブラリテンプレートを使用するか、独自のテンプレートを直接入力して設定できます。

マッピングされたクレームは、Auth0 の ID トークンに自動的には追加されません。ID トークンにクレームを追加する方法については、Create custom claimsを参照してください。

​

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

マッピングテンプレートでは、以下の options.attribute_map オブジェクトのプロパティをサポートしています。テンプレートは、有効なキーと値のペアを含む JSON 形式である必要があります。

Property	Required?	Description
mapping_mode	必須	受信したクレームをマッピングする方法。
userinfo_scope	任意	認可時に IdP に要求するスコープ。これにより、UserInfo エンドポイントで利用可能なクレームが決まります。
attributes	必須	受信したクレームのマッピング詳細を含むオブジェクト。

​

マッピングモード

mapping_mode プロパティは、IdP から受け取ったクレームを Auth0 ユーザープロファイルにマッピングする方法を定義します。mapping_mode では、次の値を使用できます。

値	説明
use_map	指定されたテンプレートを使用してデータをマッピングします。
bind_all	IdP から提供されたすべてのデータ要素をコピーします。

​

使用が制限されたクレーム

一部のクレームは 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.connection	次のプロパティが含まれます。 id: 接続の一意の識別子 (例: con_4423423423432423) 。 strategy: 接続のストラテジー (例: oidc) 。
context.tokenset	次のプロパティが含まれます。 access_token: IdP から送信された、検証済みのアクセストークン全体。 <claim name>: IdP から送信された任意の ID トークンのクレーム。
context.userinfo	次のプロパティが含まれます。 <claim name>: IdP の UserInfo エンドポイントから提供される、利用可能な任意のクレーム。

​

例

​

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

この例では、ID トークン のデータを使用して、一般的なユーザークレームを 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}",
        . . .
    }
}