Pushed Authorization Requests（PAR）を使用する認可コードフロー

Pushed Authorization Requests（PAR）を認可コードフローで使用する方法について説明します。

Highly Regulated Identity 機能を利用するには、Highly Regulated Identity add-on を含む Enterprise Plan が必要です。詳しくは Auth0 Pricing をご覧ください。

Pushed Authorization Request (PAR) は、認可リクエストを 認可サーバー に直接送信するためのバックエンドプロトコルです。これは、高い価値を持つシナリオで API を保護することを目的とした Financial-Grade API (FAPI) Security Profile 1.0 の技術コンポーネントです。

​

仕組み

PAR を使用すると、アプリケーションは OAuth 2.0 の認可リクエストのパラメーターを、認可サーバーの PAR エンドポイント (1) に直接送信できます。これに対して、認可サーバーは /authorize エンドポイント (3) の呼び出し時に使用する request URI 値 request_uri (2) を返します。request_uri は /par エンドポイントに保存された認可リクエストへの参照であるため、これらのリクエストが公開されることはありません (4)。詳しくは、Push Authorization Requests を設定する をご覧ください。

​

利点

PAR を使用する利点の 1 つは、早い段階で検証を行えることです。認可コードフロー など、他の OAuth 2.0 フローでは、エンドユーザーは検証のために認可サーバーへリダイレクトされます。PAR では、エンドユーザーがリダイレクトされる前に、認可リクエストの開始時点でリクエストパラメータが検証されます。エラーページを表示するためにユーザーをリダイレクトするのは望ましくありません。

PAR では、認可リクエストはバックチャネル経由でも送信されます。フロントチャネル通信は、付加された HTTPS クエリパラメータ (GET、POST) を通じて仲介者 (たとえばブラウザー) に依存します。メッセージは直接送信されません。一方、バックチャネル通信では、より直接的な方法として、認証されたバックエンドリクエストの本文で送信されます。

プッシュ認可リクエストはバックチャネル経由で送信されるため、次の利点があります。

• 認可サーバーは、リクエストの送信元を信頼でき、リクエストがエンドユーザーによって改変されていないことも保証できます。
• リクエストの詳細がブラウザーのアドレスバーや履歴に露出せず、その時点でプライバシーが保たれます。
• URL の長さに関する制限を気にする必要がありません。

​

制限事項

• リクエストのペイロードの最大サイズは 10 KB です。
• 現在、パブリックアプリケーションはサポートされていません。詳しくは、パブリックアプリケーションと機密アプリケーションをお読みください。

​

PAR エンドポイントを呼び出す

​

要件

PARエンドポイントを呼び出すには、次の要件を満たす必要があります。

• リクエストのコンテンツタイプをapplication/x-www-form-urlencodedに設定します。
• 渡すすべてのパラメーターには文字列を使用します。
• リクエストに、アプリケーションの認証方式を指定する追加のパラメーターを含めます。PARをサポートしているのは機密クライアントのみであるため、使用できるアプリケーションの認証方式は次のとおりです: Client Secret、Private Key JWT、およびmTLSです。アクセストークンを取得する際は、/tokenエンドポイントでも同じアプリケーションの認証方式を使用する必要があります。

​

サポートされているパラメーター

PAR エンドポイントで保存および処理されるのは、次のもののみです。

• 認可エンドポイントで認識される、標準の OAuth 2.0 パラメーターと該当する拡張機能。
• ext- 接頭辞が付いたカスタム認可パラメーターを最大 10 個。

PAR は、それ以外のカスタム認可パラメーターを無視します。カスタム認可パラメーターは、Auth0 Actions と Logs では利用できません。

Actions でカスタム認可パラメーターを使用する場合は、ext- を接頭辞として付ける必要があります。そうしないと、利用できません。

​

PARリクエストの例

curl --location --request POST https://$tenant/oauth/par \
  -H "content-type: application/x-www-form-urlencoded" \
  -d "client_id=CLIENT_ID"\
"&client_secret=CLIENT_SECRET"\
"&redirect_uri=https://jwt.io"\
"&audience=urn:my-notes-api"\
"&scope=openid%20profile%20read:notes"\
"&response_type=code"

​

PARレスポンスの例

次のPARレスポンス例では:

• request_uri は、保存された認可リクエストを参照するためのものです。リクエストの値は、request_uri パラメーターとして GET /authorize endpoint に渡されます。
• expires_in は、request_uri の有効期間 (秒数) を示します。この時間を過ぎると、request_uri は使用されていない場合に期限切れになります。30秒という有効期限は固定値で、変更できません。

HTTP/1.1 201 Created
 Content-Type: application/json

 {
  "request_uri":
    "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
  "expires_in": 30
 }

​

レート制限

Essential、Professional、Enterprise の本番テナントでは、PAR エンドポイントへの呼び出しは、標準の Authentication API のレート制限に含まれます。詳細については、レート制限の構成を参照し、ご利用のサブスクリプションタイプをクリックしてください。次に、Authentication API をクリックしてください。

​

認可エンドポイントを呼び出す

アプリケーションは、認可リクエスト内で /oauth/par エンドポイントから返された request_uri の値を使用し、ユーザーエージェントを認可エンドポイントにリダイレクトします。request_uri パラメーターの詳細については、Configure Push Authorization Requestsをご覧ください。

次の例では、ユーザーエージェントが次の HTTP リクエストを行うよう指定します。

GET /authorize?client_id=CLIENT_ID&request_uri=urn%3Aietf%3Aparam...qrwSI HTTP/1.1 Host: TENANT.auth0.com

有効な request_uri であれば、認可フロー の残りの流れは同じです。

​

検証

• PAR は、このステージで他の認可リクエストと同様に、認可サーバーによって再度検証されます。
• request_uri の値は 1 回しか使用できません。
• 有効期限切れの request_uri は認可サーバーによって拒否されます。
• テナントレベルまたはクライアントレベルで PAR が必須の場合、PAR ではないリクエストは拒否されます。

​

さらに詳しく

• Pushed Authorization Requests (PAR) の設定