始める前に
Auth0 で DPoP を有効にする前に、次の点を確認してください。
- アップストリームのアイデンティティプロバイダーが、仕様 RFC-9449 に準拠した DPoP をサポートしている必要があります。
- 既存の OIDC または Okta のエンタープライズ接続があるか、新たに作成できる必要があります。Auth0 でエンタープライズ接続を作成する方法については、Enterprise Connections を参照してください。
- 接続は、Token Vault を使用するように設定されていてはなりません。
- 接続では、Proof Key for Code Exchange (PKCE) を使用する 認可コードフロー + PKCE を使用する必要があります。アイデンティティプロバイダーが PKCE をサポートしている場合、これはアップストリームで有効になります。
- 接続のタイプは
back_channelである必要があります。
接続先の IdP のサポートを確認する
DPoP がサポートされているかどうかを確認するには、IdP の OIDC ディスカバリー ドキュメントを確認します:dpop_signing_alg_values_supported を探します。
例
署名アルゴリズムを選択する
DPoP を設定する前に、次の中からサポート対象の署名アルゴリズムを選択してください。
アイデンティティプロバイダーで別のアルゴリズムが明示的に要求されていない限り、ES256 を選択してください。
DPoP を有効にする
DPoP を有効にしてアルゴリズムを選択するには、Auth0 Dashboard または Management API を使用します。- Auth0 Dashboard
- Management API
Auth0 Dashboard では、次の手順で行います。
- Authentication > Enterprise に移動し、設定する接続を選択します。
- 資格情報 タブを選択します。
- Enable Demonstrating Proof of Possession (DPoP) のチェックボックスをオンにします。
- DPoP の Signing Algorithms の下にあるメニューで、使用するアルゴリズムを選択します。

- Save を選択します。
DPoP をテストする
DPoP を有効にしたら、ログインフローを開始して設定をテストします。- ご利用のアプリケーションを開きます。
- 設定済みのエンタープライズ接続を使用してログインフローを開始します。
- アップストリームのアイデンティティプロバイダーでログインを完了します。
- 確認のため、Auth0 Dashboard > Monitoring > Logs に移動し、Auth0 のログ を確認します。
dpop_signing_alg と idp_token_type: "dpop" の値は、Auth0 が設定されたアルゴリズムを使用して DPoP proof を送信し、IdP が DPoP にバインドされたトークンを発行したことを示しています。upstream_userinfo_fetch オブジェクトは、User Information エンドポイントが呼び出された場合にのみ存在します。dpop_bound フィールドは、/userinfo エンドポイントへの GET リクエストが正常に DPoP にバインドされた場合にのみ存在します。
DPoP を無効にする
Auth0 Dashboard または Management API を使用して DPoP を無効にできます。- Auth0 Dashboard
- Management API
- Authentication > Enterprise に移動し、設定する接続を選択します。
- 資格情報 タブを選択します。
- Enable Demonstrating Proof of Possession (DPoP) チェックボックスをオフにします。
- Save を選択します。
トラブルシューティング
OIDC および Okta のエンタープライズ接続に関する DPoP 設定の問題を診断して解決するには、以下の推奨事項を確認してください。Auth0 の設定を確認する
トラブルシューティングを開始する前に、Auth0 で DPoP の設定を確認してください。- Auth0 Dashboard > Authentication > Enterprise に移動します。
- Okta または OIDC の接続を選択します。
- Advanced Settings > Grant Types に移動し、その接続が Token Vault で設定されていないことを確認します。Token Vault が選択されていないことを確認してください。
- Management API の Update a connection エンドポイントを使用して、
dpop_signing_alg設定を確認します。
dpop_signing_alg のレスポンスで、次の点を確認してください。
- アルゴリズムがサポート対象の値、ES256、ES384、ES512、Ed25519 のいずれかであることを確認します。
- 接続で、認可コードフロー + PKCE を使用したバックチャネルのトークン交換が使われていることを確認します。Implicit Flow のようなフロントチャネル通信では DPoP はサポートされておらず、接続でフロントチャネルが使われている場合は自動的に無効になります。
テナントログに DPoP フィールドが表示されない
エンタープライズ接続の Auth0 の成功 (s) または失敗 (f) のログに dpop_signing_alg または idp_token_type フィールドが含まれていない場合、原因として次のいずれかが考えられます。
- DPoP が設定されていません。上記の説明に従って、Management API の Update a connection エンドポイントを使用し、接続の
optionsobject でdpop_signing_algが設定されていることを確認してください。 - サポートされていないアルゴリズムです。Auth0 は ES256、ES384、ES512、Ed25519 をサポートしています。
dpop_signing_algにサポート対象外の値 (たとえば RS256) が設定されている場合、DPoP はエラーなしで無効化されます。エラーはログにも記録されません。接続を更新して、ES256、ES384、ES512、または Ed25519 を使用してください。 - フロントチャネル接続です。DPoP では、接続タイプとして
back_channeltoken exchange が必要です。グラントタイプを更新して、認可コードフローや認可コードフロー + PKCE などの バックチャネル フローに変更する必要がある場合があります。
DPoP を有効にした後に認証が失敗する
Okta または OIDC のエンタープライズ接続で DPoP を有効にした後、ユーザーが認証を完了できない場合は、以下のトラブルシューティング方法を確認してください。 テナントログには、dpop_signing_alg を含む失敗 (f) イベントが次のように表示されるはずです。
idp_token_type が含まれていない点に注意してください。これは、Auth0 が IdP から token を受け取っていないためです。
アイデンティティプロバイダーが DPoP proof を拒否する
IdP が、トークン交換中に Auth0 から送信される DPoP proof を明示的に拒否することがあります。IdP がinvalid_dpop_proof エラーを返し、その結果、認証が失敗する場合があります。
IdP が DPoP をサポートしていることと、設定したアルゴリズム (ES256、ES384、ES512、または Ed25519) がサポート対象の一覧に含まれていることを確認してください。これは、IdP の OpenID Connect ディスカバリードキュメントにアクセスすると確認できます。
dpop_signing_alg_values_supported を確認してください。このフィールドがない場合、IdP は DPoP をサポートしていない可能性があります。このフィールドに Auth0 がサポートしていない algorithms しか含まれていない場合 (たとえば RS256 のみ) 、この接続では DPoP を使用できません。この接続で DPoP を無効にするか、ES256、ES384、ES512、または Ed25519 をサポートするよう IdP に問い合わせてください。
DPoP 以外の理由でトークン交換が失敗する
dpop_signing_alg を含む失敗ログが見つかっても、必ずしも DPoP が原因で失敗したとは限りません。Auth0 では、DPoP が設定されていると、根本原因が DPoP と無関係な場合でも、すべての失敗ログに DPoP のメタデータが付加されます。たとえば、期限切れの認可コードや無効なクライアント資格情報が原因で、認証が失敗することがあります。
実際の原因を特定するには、失敗ログ内のエラーの説明を確認してください。DPoP に起因しない一般的なエラーには、invalid_grant、invalid_client、ID トークン署名の検証失敗などがあります。
DPoP キーの生成に失敗する
Auth0 は DPoP proof ごとに一時的なキーペアを生成します。キーの生成に失敗すると、トークン リクエストが送信される前に認証に失敗します。これは一時的なサーバー側の問題です。ユーザーに、認証を再試行するよう案内してください。IdP トークンのバインド
ユーザーの認証は成功しているものの、Auth0 テナントログに"idp_token_type": "bearer" と表示される場合は、Auth0 が DPoP proof を送信していても、IdP がトークンを DPoP にバインドしていない可能性があります。RFC-9449 によれば、これは準拠した動作です。IdP は DPoP にバインドされたトークンを発行するかどうかを完全に制御しており、次のような理由でトークンをバインドしないことがあります。
- IdP のポリシーで、要求されたリソースまたはアプリケーションに対して DPoP が必須とされていない。
- IdP は proof をエラーなく受け入れていても、DPoP をサポートしていない。
- IdP が DPoP proof の処理中に内部的な問題を起こした。
DPoP nonce の処理
一部の IdP では、§8 の DPoP proof に従ってnonce が必要です。IdP が DPoP-Nonce レスポンスヘッダーを付けて HTTP 400 を返した場合、Auth0 は提供された nonce を使ってトークンリクエストを自動的に再試行します。これは透過的に処理されるため、テナントログには失敗として表示されません。
use_dpop_nonce エラーコードは、Auth0 と IdP の間で使われる内部的なプロトコルシグナルです。問題が発生していることを示すものではありません。失敗したログエントリの理由として use_dpop_nonce が表示されることはありません。nonce を使った再試行でも失敗した場合 (たとえば、2 回目の試行でアイデンティティプロバイダーが invalid_dpop_proof を返した場合) は、最終的なエラーが失敗ログに表示されます。
nonce を必要とするアイデンティティプロバイダーを使用する接続で認証の失敗が繰り返し発生する場合は、Auth0 とアイデンティティプロバイダー間のネットワーク接続を確認してください。nonce のやり取りではトークンエンドポイントとの間で 2 回の往復通信が必要になるため、ネットワークタイムアウトの影響を受けやすくなります。