> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 暗号学的トークン バインディングを使用して OIDC および Okta Enterprise 接続を保護する方法について説明します。

# Demonstrating Proof-of-Possession（DPoP）を使用して Enterprise 接続を構成する

Demonstrating Proof-of-Possession (DPoP) は、[OAuth 2.0 フレームワーク拡張](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/)です。DPoP プロトコルと、送信者制約付きトークンにおけるその使用方法の詳細については、[Demonstrating Proof-of-Possession (DPoP) ](/ja/docs/secure/sender-constraining)を参照してください。IDプロバイダー (IdP) として Okta または OpenID Connect (OIDC) を使用し、Auth0 で Enterprise 接続として構成している場合は、DPoP を有効にして構成し、IdP からのアクセストークンを暗号鍵にバインドできます。DPoP を使用すると、トークンのリプレイ攻撃を防止でき、[Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) OIDC](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) Security Level 1 や [Financial-grade API (FAPI) 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html) などのコンプライアンス要件への対応に役立ちます。

<Card title="開始する前に">
  Auth0 で DPoP を有効にする前に、以下を確認してください。

  * アップストリームのIDプロバイダーは、仕様 [RFC-9449](https://www.rfc-editor.org/rfc/rfc9449.html) に従って DPoP をサポートしている必要があります。
  * 既存の OIDC または Okta Enterprise 接続があるか、新たに作成できる必要があります。Auth0 で Enterprise 接続を作成する方法については、[Enterprise Connections](/ja/docs/authenticate/enterprise-connections)を参照してください。
  * 接続で [Token Vault](/ja/docs/secure/call-apis-on-users-behalf/token-vault/configure-token-vault) が使用されるように構成されていてはなりません。
  * 接続では、Proof Key for Code Exchange (PKCE) [Authorization Code Flow + PKCE](docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce#authorization-code-flow-with-proof-key-for-code-exchange-pkce) を使用する必要があります。IDプロバイダーが PKCE をサポートしている場合、これはアップストリームで有効になります。
  * 接続の type は `back_channel` である必要があります。
</Card>

<div id="verify-upstream-idp-support">
  ## 上流IdPのサポートを確認する
</div>

DPoPのサポート状況を確認するには、IdPのOIDCディスカバリードキュメントを確認します。

```curl theme={null}
curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration
```

レスポンス内で、DPoP のサポート対象の値 `dpop_signing_alg_values_supported` を探します。

**例**

```
{
  "dpop_signing_alg_values_supported": ["ES256", "ES384", "Ed25519", "ES512", "RS256"] 
},
```

<div id="choose-a-signing-algorithm">
  ## 署名アルゴリズムを選択する
</div>

DPoP を設定する前に、サポートされている[署名アルゴリズム](/ja/docs/get-started/applications/signing-algorithms)を以下のオプションから選択します。

| **Algorithm** | **Description**               | **When to use**                         |
| ------------- | ----------------------------- | --------------------------------------- |
| ES256         | P-256 曲線と SHA-256 を使用する ECDSA | IDプロバイダーが ES256 をサポートしている場合。            |
| ES384         | P-384 曲線と SHA-384 を使用する ECDSA | IDプロバイダーで ES384 が必要な場合。                 |
| ES512         | P-521 曲線と SHA-512 を使用する ECDSA | IDプロバイダーで ES512 が必要な場合。                 |
| Ed25519       | Curve25519 を使用する EdDSA        | コンプライアンス要件により、IDプロバイダーで Ed25519 が必要な場合。 |

IDプロバイダーで別のアルゴリズムが明示的に必要とされていない限り、ES256 を選択してください。

<div id="enable-dpop">
  ## DPoP を有効にする
</div>

DPoP を有効にしてアルゴリズムを選択するには、Auth0 Dashboard または Management API を使用します。

<Tabs>
  <Tab title="Auth0 Dashboard">
    Auth0 Dashboard では、次の手順を実行します。

    1. **[Authentication > Enterprise](https://manage.auth0.com/dashboard/#/connections/enterprise/)** に移動し、設定する接続を選択します。
    2. **Credentials** タブを選択します。
    3. **Enable Demonstrating Proof of Possession (DPoP)** のチェックボックスをオンにします。
    4. DPoP の Signing Algorithms のメニューで、使用するアルゴリズムを選択します。
           <Frame>
             <img src="https://mintcdn.com/translations/mMSz-RNYLuOm2GmQ/docs/images/cdy7uua7fh8z/enable-dpop-dashboard.png?fit=max&auto=format&n=mMSz-RNYLuOm2GmQ&q=85&s=f3e39b5fe0ee23d1cf499d45e0e2484f" alt="DPoP を有効にしてアルゴリズムを選択する" width="514" height="217" data-path="docs/images/cdy7uua7fh8z/enable-dpop-dashboard.png" />
           </Frame>
    5. **Save** を選択します。
  </Tab>

  <Tab title="Management API">
    Management API を使用するには、[Management API アクセストークン](/ja/docs/secure/tokens/access-tokens/management-api-access-tokens)を取得する必要があります。

    `options` オブジェクトに `dpop_signing_alg_values_supported` を含めて、[接続を更新する](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) エンドポイントに `PATCH` リクエストを送信します。

    ```curl theme={null}
    PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
    Content-Type: application/json
    Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

    {
      "options": {
        "dpop_signing_alg": "ES256"
      }
    }
    ```

    <Callout icon="file-lines" color="#0EA5E9" iconType="regular">
      `options` パラメーターを `PATCH` すると、`options` オブジェクト全体が上書きされます。データの欠落やその他の問題を避けるため、`options` を `PATCH` する際は必要なプロパティがすべて含まれていることを確認してください。
    </Callout>

    プレースホルダーの値を置き換えます。

    * **YOUR\_DOMAIN**: Auth0 テナントのドメイン。例: `travel0.us.auth0.com`
    * **YOUR\_CONNECTION\_ID**: OIDC または Okta Enterprise 接続の ID
    * **YOUR\_MANAGEMENT\_API\_TOKEN**: `update:connections` スコープを持つ Management API トークン
  </Tab>
</Tabs>

<div id="test-dpop">
  ## DPoP をテストする
</div>

DPoP を有効にしたら、ログインフローを開始して設定をテストします。

1. アプリケーションに移動します。
2. 設定済みの Enterprise 接続を使用してログインフローを開始します。
3. 上流のIDプロバイダーでログインを完了します。
4. [**Auth0 Dashboard > Monitoring > Logs**](https://manage.auth0.com/#/logs) に移動し、[Auth0 ログ](/ja/docs/deploy-monitor/logs#logs) で確認します。

ログエントリ内の成功したトランザクションは、次のようになります。

```
{
  "type": "s",
  "description": "Success Login",
  "details": {
    "dpop_signing_alg": "ES256",
    "idp_token_type": "dpop",
    "upstream_userinfo_fetch": {
      "status": "SUCCESS",
      "dpop_bound": true
    }
   }
}
```

`dpop_signing_alg` と `idp_token_type: "dpop"` の値は、Auth0 が設定されたアルゴリズムを使用して DPoP プルーフを送信し、IdP が DPoP にバインドされたトークンを発行したことを示します。`upstream_userinfo_fetch` オブジェクトは、[User Information](https://auth0.com/docs/api/authentication/user-profile/get-user-info) エンドポイントが呼び出された場合にのみ存在します。`dpop_bound` フィールドは、`/userinfo` エンドポイントへの `GET` リクエストが正常に DPoP バインドされた場合にのみ存在します。

<div id="disable-dpop">
  ## DPoP を無効にする
</div>

Auth0 Dashboard または Management API を使用して、DPoP を無効にできます。

<Tabs>
  <Tab title="Auth0 Dashboard">
    1. [**Authentication > Enterprise**](https://manage.auth0.com/dashboard/#/connections/enterprise/) に移動し、設定する接続を選択します。
    2. **Credentials** タブを選択します。
    3. **Enable Demonstrating Proof of Possession (DPoP)** チェックボックスをオフにします。
    4. **Save** を選択します。
  </Tab>

  <Tab title="Management API">
    DPoP を無効にするには、接続設定から `dpop_signing_alg` プロパティを削除します。

    ```curl theme={null}
    PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
    Content-Type: application/json
    Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

    {
      "options": {

      }
    }
    ```

    <Callout icon="file-lines" color="#0EA5E9" iconType="regular">
      `options` パラメーターを `PATCH` すると、`options` オブジェクト全体が上書きされます。データの欠落やその他の問題を避けるため、`options` を `PATCH` する際は、必要なプロパティがすべて含まれていることを確認してください。
    </Callout>
  </Tab>
</Tabs>

<div id="troubleshoot">
  ## トラブルシューティング
</div>

以下の推奨事項を参照して、OIDC および Okta Enterprise 接続の DPoP 設定に関する問題の診断と解決に役立ててください。

<div id="check-auth0-configuration">
  ### Auth0 の設定を確認する
</div>

トラブルシューティングを開始する前に、Auth0 で DPoP の設定を確認してください。

1. [**Auth0 Dashboard > Authentication > Enterprise**](https://manage.auth0.com/#/connections/enterprise) に移動します。
2. Okta または OIDC の接続を選択します。
3. **Advanced Settings > Grant Types** に移動し、その接続で Token Vault が**有効になっていない**ことを確認します。Token Vault が選択されていないことを確認してください。
4. Management API の [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) エンドポイントを使用して、`dpop_signing_alg` 設定を確認します。

```curl theme={null}
GET https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN
```

`dpop_signing_alg` のレスポンスで、次の点を確認してください。

* アルゴリズムがサポート対象の値 (**ES256**、**ES384**、**ES512**、**Ed25519**) のいずれかであることを確認します。
* 接続で、[Authorization Code Flow + PKCE](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) を使用するバックチャネルのトークン交換が有効になっていることを確認します。DPoP は、[Implicit Flow](/ja/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) のようなフロントチャネル通信ではサポートされておらず、接続でフロントチャネルを使用している場合は暗黙的に無効になります。

<div id="dpop-fields-missing-in-tenant-logs">
  #### テナントログに DPoP フィールドがない
</div>

エンタープライズ接続の Auth0 の成功 (`s`) または失敗 (`f`) ログに `dpop_signing_alg` または `idp_token_type` フィールドが含まれていない場合は、次のいずれかが原因である可能性があります。

* DPoP が設定されていません。前述のとおり、Management API の [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) エンドポイントを使用して、接続の `options` オブジェクトで `dpop_signing_alg` が設定されていることを確認してください。
* サポート対象外のアルゴリズム。Auth0 でサポートされているのは ES256、ES384、ES512、Ed25519 です。`dpop_signing_alg` にサポート対象外の値 (たとえば RS256) が設定されている場合、DPoP は暗黙的に無効になります。エラーはログに記録されません。接続を更新し、ES256、ES384、ES512、または Ed25519 を使用してください。
* フロントチャネル接続。DPoP では、接続タイプとして `back_channel` トークン交換が必要です。[grant type を更新](/ja/docs/get-started/applications/update-grant-types#update-grant-types) して、Authorization Code Flow や Authorization Code Flow + PKCE などのバックチャネルフローに変更する必要がある場合があります。

<div id="authentication-fails-after-enabling-dpop">
  ### DPoP を有効にした後、認証が失敗する
</div>

Okta または OIDC の Enterprise 接続で DPoP を有効にした後にユーザーが認証を完了できない場合は、次のトラブルシューティング方法を確認してください。

テナントログには、`dpop_signing_alg` を含む失敗 (`f`) イベントが次のように表示されます。

```bash theme={null}
{
  "type": "f",
  "description": "Failed Login",
  "details": {
    "error": "dpop_signing_alg"
  }
}
```

失敗時には、Auth0 が IdP からトークンを受け取っていないため、`idp_token_type` は含まれません。

<div id="identity-provider-rejects-dpop-proof">
  #### IDプロバイダーが DPoP プルーフを拒否する
</div>

IdP が、トークン交換中に Auth0 が送信する DPoP プルーフを明示的に拒否する場合があります。IdP は `invalid_dpop_proof` エラーを返すことがあり、その結果、認証に失敗します。

IdP が DPoP をサポートしていること、および設定したアルゴリズム (ES256、ES384、ES512、または Ed25519) がサポート対象の一覧に含まれていることを確認してください。これは、IdP の OpenID Connect ディスカバリードキュメントにアクセスして確認できます。

```curl theme={null}
curl https://YOUR_IDP_DOMAIN/.well-known/openid-configuration
```

IdP のレスポンスで `dpop_signing_alg_values_supported` を確認してください。このフィールドが存在しない場合、IdP は DPoP をサポートしていない可能性があります。このフィールドに Auth0 がサポートしていないアルゴリズムしか含まれていない場合 (たとえば RS256 のみ) 、この接続では DPoP を使用できません。この接続では DPoP を無効にするか、ES256、ES384、ES512、または Ed25519 をサポートするよう IdP に依頼してください。

<div id="token-exchange-fails-for-a-non-dpop-reason">
  #### DPoP 以外の理由でトークン交換が失敗する
</div>

`dpop_signing_alg` を含む失敗ログが見つかっても、必ずしも DPoP が原因で失敗したとは限りません。Auth0 では DPoP が設定されている場合、根本原因が無関係であっても、すべての失敗ログに DPoP のメタデータが追加されます。たとえば、認可コードの有効期限切れや無効なクライアント認証情報により、認証が失敗することがあります。

実際の原因を特定するには、失敗ログのエラー説明を確認してください。DPoP に起因しない一般的なエラーには、`invalid_grant`、`invalid_client`、および IDトークン の署名検証エラーがあります。

<div id="dpop-key-generation-fails">
  #### DPoP キーの生成に失敗する
</div>

Auth0 は、各 DPoP プルーフに対して一時的な鍵ペアを生成します。鍵の生成に失敗すると、トークンリクエストが送信される前に認証が失敗します。これは一時的なサーバー側の問題です。ユーザーに認証を再試行するよう案内してください。

<div id="idp-token-binding">
  #### IdP トークンのバインド
</div>

ユーザー認証は成功しているにもかかわらず、Auth0 テナントログに `"idp_token_type": "bearer"` と表示される場合、Auth0 が DPoP プルーフを送信していても、IdP がトークンを DPoP にバインドしていない可能性があります。RFC 9449 では、これは準拠した動作です。IDプロバイダーは、DPoP にバインドされたトークンを発行するかどうかを完全に制御しているため、次の理由でトークンがバインドされないことがあります。

* IdP のポリシーで、要求されたリソースまたはアプリケーションに対して DPoP が必須になっていない。
* IdP は、プルーフをエラーなく受け入れていても、DPoP をサポートしていない。
* IdP が、DPoP プルーフの処理中に内部的な問題に遭遇した。

Auth0 はこれを「ダウングレード」イベントとして追跡します。認証は標準の Bearer トークンで正常に完了します。

コンプライアンス要件上 DPoP にバインドされたトークンが必要な場合は、トークンがバインドされない理由を確認するため、IdP に問い合わせることをお勧めします。Auth0 では、IDプロバイダーのトークンレスポンスに対して DPoP バインディングを強制することはできません。

<div id="dpop-nonce-handling">
  #### DPoP nonce の取り扱い
</div>

一部の IdP では、[§8 の DPoP proof](https://www.rfc-editor.org/rfc/rfc9449.html#name-authorization-server-provid) に従って `nonce` が必要です。IdP から HTTP `400` と `DPoP-Nonce` レスポンスヘッダーが返された場合、Auth0 は指定された nonce を使用してトークンリクエストを自動的に再試行します。この処理は透過的に行われるため、テナントログに失敗として記録されることはありません。

`use_dpop_nonce` エラーコードは、Auth0 と IdP の間でやり取りされる内部的なプロトコルシグナルです。問題を示すものではありません。失敗ログエントリの理由として `use_dpop_nonce` が表示されることはありません。nonce を付けて再試行しても失敗した場合 (たとえば、IDプロバイダーが 2 回目の試行で `invalid_dpop_proof` を返した場合) 、失敗ログには最終的なエラーが表示されます。

IDプロバイダーが nonce を必要とする接続で認証失敗が繰り返し発生する場合は、Auth0 と IDプロバイダー間のネットワーク接続を確認してください。nonce のやり取りではトークンエンドポイントに対して 2 往復の通信が必要になるため、ネットワークタイムアウトの影響を受けやすくなります。
