メインコンテンツまでスキップ

8. Authorization Server-Provided Nonce (認可サーバー提供のノンス)

8. Authorization Server-Provided Nonce (認可サーバー提供のノンス)​

このセクションでは、サーバーが提供する不透明なノンスを使用して DPoP 証明の寿命を制限できるメカニズムを指定します。このようなメカニズムを採用しない場合、クライアント（エンドユーザーを含む可能性がある）を制御している悪意のある当事者は、将来の任意の時点で使用できる DPoP 証明を作成できます。

認可サーバーによって提供されるノンス値を DPoP 証明に含めることは、DPoP 証明の寿命を制限するために認可サーバーによって使用される場合があります (MAY)。サーバーは、新しい DPoP ノンスチャレンジを発行するタイミングと、それがいつ必要かを決定し、それによって後続の DPoP 証明でノンス値を使用することを要求します。サーバーがその決定を行うロジックは、この文書の範囲外です。

認可サーバーは、送信される DPoP 証明にクライアントが含めるためのノンス値を提供することができます (MAY)。この場合、認可サーバーは、ノンスを含まないリクエストに対して、[RFC6749] のセクション 5.2 に従い、エラーコード値として use_dpop_nonce を使用して、HTTP 400 (Bad Request) エラーレスポンスで応答します。認可サーバーは、レスポンスに DPoP-Nonce HTTP ヘッダーを含め、後続のリクエストを送信する際に使用するノンス値を提供します。ノンス値は予測不可能でなければなりません (MUST)。この同じエラーコードは、ノンスの不一致があったときに新しいノンス値を提供する場合にも使用されます。クライアントは通常、use_dpop_nonce エラーとそれに伴うノンス値を受け取ると、提供された新しいノンス値を使用してリクエストを再試行します。

たとえば、認可サーバーがノンスを必要とする場合に、ノンスなしのトークンリクエストへの応答として、認可サーバーは以下のような DPoP-Nonce 値を返して、DPoP 証明に含めるノンス値を提供できます。

HTTP/1.1 400 Bad Request
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

{
 "error": "use_dpop_nonce",
 "error_description":
   "Authorization server requires nonce in DPoP proof"
}

  図 20: ノンスのないトークンリクエストに対する HTTP 400 レスポンス

他の HTTP ヘッダーや JSON フィールドもエラーレスポンスに含まれる場合がありますが (MAY)、DPoP-Nonce ヘッダーは 2 つ以上あってはなりません (MUST NOT)。

ノンスを受信すると、クライアントは、DPoP 証明の nonce クレームに提供されたノンス値を含む DPoP 証明を使用して、トークンリクエストを再試行することが期待されます。ノンスを含むこのような DPoP 証明のエンコードされていない JWT ペイロードの例を以下に示します。

{
 "jti": "-BwC3ESc6acc2lTc",
 "htm": "POST",
 "htu": "https://server.example.com/token",
 "iat": 1562262616,
 "nonce": "eyJ7S_zG.eyJH0-Z.HX4w-7v"
}

       図 21: ノンス値を含む DPoP 証明ペイロード

ノンスはクライアントにとって不透明です。

DPoP 証明の nonce クレームが、認可サーバーによってクライアントに最近提供されたノンスと正確に一致しない場合、認可サーバーはリクエストを拒否しなければなりません (MUST)。拒否レスポンスには、後続のリクエストに使用する新しいノンス値を提供する DPoP-Nonce HTTP ヘッダーが含まれる場合があります (MAY)。

その意図は、クライアントは 1 つのノンス値のみを保持する必要があり、サーバーは最近のノンスのウィンドウを保持する必要があるということです。そうは言っても、サーバーとクライアントの保存されたノンス値が異なる一時的な状況が発生する可能性があります。ただし、この状況は自己修正機能があります。拒否メッセージがあれば、サーバーは使用させたいノンス値をクライアントに送信でき、クライアントはそのノンス値を保存してリクエストを再試行できます。クライアントやサーバーが保存されたノンス値を破棄した場合でも、失敗したリクエストへの応答時や再試行時に新しいノンス値を伝達できるため、この状況も自己修正機能があります。

Cross-Origin Resource Sharing (CORS) [WHATWG.Fetch] を使用するブラウザベースのクライアントアプリケーションは、デフォルトで CORS セーフリストレスポンス HTTP ヘッダーにしかアクセスできないことに注意してください。アプリケーションが DPoP-Nonce HTTP レスポンスヘッダー値を取得して使用できるようにするには、サーバーは Access-Control-Expose-Headers レスポンスヘッダーリスト値に DPoP-Nonce を含めることで、アプリケーションが利用できるようにする必要があります。

8.1. ノンスの構文​

[RFC6749] で使用されている ABNF のノンス構文（scope-token 構文と同じ）を以下に示します。

nonce = 1*NQCHAR

                        図 22: ノンス ABNF

8.2. 新しいノンス値の提供​

クライアントが使用する新しいノンス値をいつ提供するかは、認可サーバー次第です。クライアントは、サーバーが新しいノンス値を提供するまで、DPoP 証明で既存の提供されたノンスを使用することが期待されます。

認可サーバーは、最初のノンスが提供されたのと同じ方法（レスポンスで DPoP-Nonce HTTP ヘッダーを使用する）で新しいノンスを提供することができます (MAY)。DPoP-Nonce HTTP ヘッダーフィールドは、第 8.1 節で定義されているノンス構文を使用します。これが発生するたびに、余分なプロトコルラウンドトリップが必要になります。

新しいノンス値を提供するより効率的な方法も定義されており、前のリクエストからの HTTP 200 (OK) レスポンスに DPoP-Nonce HTTP ヘッダーを含めます。クライアントは、次のトークンリクエストおよび認可サーバーが新しいノンスを提供するまでの後続のすべてのトークンリクエストに、提供された新しいノンス値を使用しなければなりません (MUST)。

DPoP-Nonce HTTP ヘッダーを含むレスポンスは、キャッシュ不可であるべきであり（例：GET リクエストへの応答で Cache-Control: no-store を使用）、レスポンスが後続のリクエストの処理に使用され、その結果として古いノンス値が使用されるのを防ぐ必要があります。

新しいノンス値を提供する 200 OK レスポンスの例を以下に示します。

HTTP/1.1 200 OK
Cache-Control: no-store
DPoP-Nonce: eyJ7S_zG.eyJbYu3.xQmBj-1

    図 23: 次のノンス値を提供する HTTP 200 レスポンス
に最終更新