メインコンテンツへスキップ
Demonstrating Proof-of-Possession (DPoP) は、OAuth 2.0 フレームワーク拡張です。DPoP プロトコルと、送信者制約付きトークンにおけるその使用方法の詳細については、Demonstrating Proof-of-Possession (DPoP) を参照してください。IDプロバイダー (IdP) として Okta または OpenID Connect (OIDC) を使用し、Auth0 で Enterprise 接続として構成している場合は、DPoP を有効にして構成し、IdP からのアクセストークンを暗号鍵にバインドできます。DPoP を使用すると、トークンのリプレイ攻撃を防止でき、Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) OIDC Security Level 1 や Financial-grade API (FAPI) 2.0 などのコンプライアンス要件への対応に役立ちます。

開始する前に

Auth0 で DPoP を有効にする前に、以下を確認してください。
  • アップストリームのIDプロバイダーは、仕様 RFC-9449 に従って DPoP をサポートしている必要があります。
  • 既存の OIDC または Okta Enterprise 接続があるか、新たに作成できる必要があります。Auth0 で Enterprise 接続を作成する方法については、Enterprise Connectionsを参照してください。
  • 接続で Token Vault が使用されるように構成されていてはなりません。
  • 接続では、Proof Key for Code Exchange (PKCE) Authorization Code Flow + PKCE を使用する必要があります。IDプロバイダーが PKCE をサポートしている場合、これはアップストリームで有効になります。
  • 接続の type は back_channel である必要があります。

​
上流IdPのサポートを確認する

DPoPのサポート状況を確認するには、IdPのOIDCディスカバリードキュメントを確認します。 
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"] 
},

​
署名アルゴリズムを選択する

DPoP を設定する前に、サポートされている署名アルゴリズムを以下のオプションから選択します。
AlgorithmDescriptionWhen to use
ES256P-256 曲線と SHA-256 を使用する ECDSAIDプロバイダーが ES256 をサポートしている場合。
ES384P-384 曲線と SHA-384 を使用する ECDSAIDプロバイダーで ES384 が必要な場合。
ES512P-521 曲線と SHA-512 を使用する ECDSAIDプロバイダーで ES512 が必要な場合。
Ed25519Curve25519 を使用する EdDSAコンプライアンス要件により、IDプロバイダーで Ed25519 が必要な場合。
IDプロバイダーで別のアルゴリズムが明示的に必要とされていない限り、ES256 を選択してください。

​
DPoP を有効にする

DPoP を有効にしてアルゴリズムを選択するには、Auth0 Dashboard または Management API を使用します。
Auth0 Dashboard では、次の手順を実行します。
  1. Authentication > Enterprise に移動し、設定する接続を選択します。
  2. Credentials タブを選択します。
  3. Enable Demonstrating Proof of Possession (DPoP) のチェックボックスをオンにします。
  4. DPoP の Signing Algorithms のメニューで、使用するアルゴリズムを選択します。
    DPoP を有効にしてアルゴリズムを選択する
  5. Save を選択します。

​
DPoP をテストする

DPoP を有効にしたら、ログインフローを開始して設定をテストします。
  1. アプリケーションに移動します。
  2. 設定済みの Enterprise 接続を使用してログインフローを開始します。
  3. 上流のIDプロバイダーでログインを完了します。
  4. Auth0 Dashboard > Monitoring > Logs に移動し、Auth0 ログ で確認します。
ログエントリ内の成功したトランザクションは、次のようになります。 
{
  "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 エンドポイントが呼び出された場合にのみ存在します。dpop_bound フィールドは、/userinfo エンドポイントへの GET リクエストが正常に DPoP バインドされた場合にのみ存在します。

​
DPoP を無効にする

Auth0 Dashboard または Management API を使用して、DPoP を無効にできます。
  1. Authentication > Enterprise に移動し、設定する接続を選択します。
  2. Credentials タブを選択します。
  3. Enable Demonstrating Proof of Possession (DPoP) チェックボックスをオフにします。
  4. Save を選択します。

​
トラブルシューティング

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

​
Auth0 の設定を確認する

トラブルシューティングを開始する前に、Auth0 で DPoP の設定を確認してください。
  1. Auth0 Dashboard > Authentication > Enterprise に移動します。
  2. Okta または OIDC の接続を選択します。
  3. Advanced Settings > Grant Types に移動し、その接続で Token Vault が有効になっていないことを確認します。Token Vault が選択されていないことを確認してください。
  4. Management API の Update a connection エンドポイントを使用して、dpop_signing_alg 設定を確認します。
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 を使用するバックチャネルのトークン交換が有効になっていることを確認します。DPoP は、Implicit Flow のようなフロントチャネル通信ではサポートされておらず、接続でフロントチャネルを使用している場合は暗黙的に無効になります。

​
テナントログに DPoP フィールドがない

エンタープライズ接続の Auth0 の成功 (s) または失敗 (f) ログに dpop_signing_alg または idp_token_type フィールドが含まれていない場合は、次のいずれかが原因である可能性があります。
  • DPoP が設定されていません。前述のとおり、Management API の Update a connection エンドポイントを使用して、接続の options オブジェクトで dpop_signing_alg が設定されていることを確認してください。
  • サポート対象外のアルゴリズム。Auth0 でサポートされているのは ES256、ES384、ES512、Ed25519 です。dpop_signing_alg にサポート対象外の値 (たとえば RS256) が設定されている場合、DPoP は暗黙的に無効になります。エラーはログに記録されません。接続を更新し、ES256、ES384、ES512、または Ed25519 を使用してください。
  • フロントチャネル接続。DPoP では、接続タイプとして back_channel トークン交換が必要です。grant type を更新 して、Authorization Code Flow や Authorization Code Flow + PKCE などのバックチャネルフローに変更する必要がある場合があります。

​
DPoP を有効にした後、認証が失敗する

Okta または OIDC の Enterprise 接続で DPoP を有効にした後にユーザーが認証を完了できない場合は、次のトラブルシューティング方法を確認してください。 テナントログには、dpop_signing_alg を含む失敗 (f) イベントが次のように表示されます。 
{
  "type": "f",
  "description": "Failed Login",
  "details": {
    "error": "dpop_signing_alg"
  }
}
失敗時には、Auth0 が IdP からトークンを受け取っていないため、idp_token_type は含まれません。

​
IDプロバイダーが DPoP プルーフを拒否する

IdP が、トークン交換中に Auth0 が送信する DPoP プルーフを明示的に拒否する場合があります。IdP は invalid_dpop_proof エラーを返すことがあり、その結果、認証に失敗します。 IdP が DPoP をサポートしていること、および設定したアルゴリズム (ES256、ES384、ES512、または Ed25519) がサポート対象の一覧に含まれていることを確認してください。これは、IdP の OpenID Connect ディスカバリードキュメントにアクセスして確認できます。 
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 に依頼してください。

​
DPoP 以外の理由でトークン交換が失敗する

dpop_signing_alg を含む失敗ログが見つかっても、必ずしも DPoP が原因で失敗したとは限りません。Auth0 では DPoP が設定されている場合、根本原因が無関係であっても、すべての失敗ログに DPoP のメタデータが追加されます。たとえば、認可コードの有効期限切れや無効なクライアント認証情報により、認証が失敗することがあります。 実際の原因を特定するには、失敗ログのエラー説明を確認してください。DPoP に起因しない一般的なエラーには、invalid_grant、invalid_client、および IDトークン の署名検証エラーがあります。

​
DPoP キーの生成に失敗する

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

​
IdP トークンのバインド

ユーザー認証は成功しているにもかかわらず、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 バインディングを強制することはできません。

​
DPoP nonce の取り扱い

一部の IdP では、§8 の DPoP proof に従って 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 往復の通信が必要になるため、ネットワークタイムアウトの影響を受けやすくなります。