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

5. DPoP Access Token Request (DPoP アクセストークンリクエスト)

5. DPoP Access Token Request (DPoP アクセストークンリクエスト)​

DPoP を使用して公開鍵にバインドされたアクセストークンをリクエストするには、クライアントは認可サーバーのトークンエンドポイントへのアクセストークンリクエストを行う際に、DPoP ヘッダーに有効な DPoP 証明 JWT を提供する必要があります。これは、グラントタイプ（例：一般的な authorization_code や refresh_token グラントタイプ、および JWT 認可グラント [RFC7523] などの拡張グラント）に関係なく、すべてのアクセストークンリクエストに適用されます。図 5 の HTTP リクエストは、認可コードグラントを使用し、DPoP ヘッダーに DPoP 証明 JWT を含めた、このようなアクセストークンリクエストを示しています。図 5 では、[RFC8792] に従って "\" を使用して行を折り返しています。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

grant_type=authorization_code\
&client_id=s6BhdRkqt\
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
&code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz-

 図 5: 認可コードを使用して DPoP 送信者制約トークンをリクエストするトークンリクエスト

DPoP HTTP ヘッダーフィールドには、有効な DPoP 証明 JWT が含まれている必要があります。DPoP 証明が無効な場合、認可サーバーは [RFC6749] のセクション 5.2 に従ってエラーレスポンスを返します。error パラメータの値は invalid_dpop_proof です。

DPoP 証明の有効性をチェックした後、アクセストークンを送信者制約するために、認可サーバーは発行されたアクセストークンを DPoP 証明の公開鍵に関連付けます。これは、第 6 節で説明されている方法で行うことができます。アクセストークン応答には、アクセストークンが DPoP 鍵にバインドされており、第 7.1 節で説明されているように使用できることをクライアントに示すために、DPoP という token_type を含める必要があります。図 6 の応答例は、このような応答を示しています。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
 "access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU",
 "token_type": "DPoP",
 "expires_in": 2677,
 "refresh_token": "Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g"
}

                   図 6: アクセストークンレスポンス

図 6 の応答例には、古いアクセストークンの有効期限が切れたときにクライアントが新しいアクセストークンを取得するために使用できるリフレッシュトークンが含まれています。アクセストークンのリフレッシュは、refresh_token グラントタイプを使用して認可サーバーのトークンエンドポイントに対して行われるトークンリクエストです。すべてのアクセストークンリクエストと同様に、クライアントは図 7 に示すように DPoP 証明を含めることでこれを DPoP リクエストにします。図 7 では、[RFC8792] に従って "\" を使用して行を折り返しています。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjY1Mjk2fQ.pAqut2IRDm_De6PR93SYmGBPXpwrAk90e8cP2hjiaG5Qs\
 GSuKDYW7_X620BxqhvYC8ynrrvZLTk41mSRroapUA

grant_type=refresh_token\
&client_id=s6BhdRkqt\
&refresh_token=Q..Zkm29lexi8VnWg2zPW1x-tgGad0Ibc3s3EwM_Ni4-g

 図 7: リフレッシュトークンを使用して DPoP バインドトークンをリクエストするトークンリクエスト

DPoP をサポートする認可サーバーが、トークンエンドポイントで有効な DPoP 証明を提示するパブリッククライアントにリフレッシュトークンを発行する場合、リフレッシュトークンは対応する公開鍵にバインドされなければなりません。リフレッシュトークンが後で新しいアクセストークンを取得するために使用される場合、そのバインディング検証されなければなりません。したがって、そのようなクライアントは、そのリフレッシュトークンを使用して新しいアクセストークンを取得するたびに、そのリフレッシュトークンを取得するために使用されたのと同じ鍵の DPoP 証明を提示しなければなりません。リフレッシュトークンのバインディングの実装詳細は、認可サーバーの裁量に任されています。認可サーバーはリフレッシュトークンを生成し検証するため、バインディングの具体的な詳細に関する相互運用性への考慮事項はありません。

認可サーバーは、アクセストークンレスポンスの token_type パラメータで値 Bearer ([RFC6750]) を使用することで、DPoP バインドされていないアクセストークンを発行することを選択できます。リフレッシュトークンも取得するパブリッククライアントの場合、これはリフレッシュトークンのみを DPoP バインドする効果があり、保護されたリソースが DPoP をサポートするように更新されていない場合でも、セキュリティ体制を向上させることができます。

アクセストークンレスポンスに非 DPoP の token_type 値が含まれている場合、DPoP が提供するアクセストークン保護は得られません。この保護がアプリケーションのセキュリティにとって重要である場合、クライアントはレスポンスを破棄しなければなりません。それ以外の場合、クライアントは通常の OAuth のやり取りと同様に続行できます。

コンフィデンシャルクライアント（つまり、認可サーバーとの認証資格情報を確立したクライアント）に発行されたリフレッシュトークンは、異なる既存のメカニズムによってすでに送信者制約されているため、DPoP 証明の公開鍵にはバインドされません。OAuth 2.0 認可フレームワーク [RFC6749] は、すでに認可サーバーに対して、リフレッシュトークンを発行したクライアントにバインドすることを要求しており、コンフィデンシャルクライアントはリフレッシュトークンを提示する際に認可サーバーに対して認証を行います。その結果、このようなリフレッシュトークンは、クライアント識別子と関連する認証要件によって送信者制約されます。この既存の送信者制約メカニズムは、特定の公開鍵に直接バインドするよりも柔軟です（たとえば、リフレッシュトークンを無効にすることなく、クライアントが資格情報をローテーションできるようになります）。

5.1. 認可サーバーメタデータ​

この文書では、DPoP に対する一般的なサポートと、認可サーバーが DPoP 証明 JWT 用にサポートする特定の JWS alg 値を示すために、以下の認可サーバーメタデータ [RFC8414] パラメータを導入します。

dpop_signing_alg_values_supported: 認可サーバーが DPoP 証明 JWT 用にサポートする JWS alg 値（[IANA.JOSE.ALGS] レジストリから）を含む JSON 配列。

5.2. クライアント登録メタデータ​

動的クライアント登録プロトコル [RFC7591] は、OAuth 2.0 クライアントメタデータを認可サーバーに動的に登録するための API を定義しています。[RFC7591] で定義されているメタデータとその登録拡張は、動的クライアント登録プロトコルが使用されていない場合でも、認可サーバーの実装に役立つ一般的なクライアントデータモデルを示唆しています。通常、このような実装には、クライアント設定を管理するための何らかのユーザーインターフェイスがあります。

この文書では、クライアントが認可サーバーにトークンをリクエストする際に常に DPoP を使用することを示すために、以下のクライアント登録メタデータ [RFC7591] パラメータを導入します。

dpop_bound_access_tokens: クライアントがトークンリクエストに常に DPoP を使用するかどうかを指定するブール値。省略した場合、デフォルト値は false です。

true の場合、認可サーバーは、DPoP ヘッダーを含まないこのクライアントからのトークンリクエストを拒否しなければなりません。

に最終更新