Pushed Authorization Requests（PAR）を使った認可コードフロー

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

ハイリーレギュレーテッドアイデンティティ機能を使用するには、エンタープライズプランとハイリーレギュレーテッドアイデンティティアドオンが必要です。詳細については、「Auth0の価格設定」を参照してください。

Pushed Authorization Request（PAR）は、認可サーバーに対して、認可要求の内容をプッシュ（直接送信）するバックエンドプロトコルです。PARは、高付加価値なAPIの保護を目的としたFinancial-Grade API (FAPI) Security Profile 1.0の技術コンポーネントです。

​

仕組み

PARでは、アプリケーションはOAuth 2.0認可要求のパラメーターを、認可サーバーのPARエンドポイントに直接プッシュできます (1) 。これに対して、認可サーバーは要求URIの値request_uriを送信し (2)、/authorizeエンドポイントを呼び出すときに使用します (3)。request_uriは、/parエンドポイントで保存された認可要求への参照であるため、これらの要求は公開されません (4)。詳細については、「プッシュ認可要求を構成する」をお読みください。

​

メリット

PARを使用するメリットの1つが早期検証です。認可コードフローなど他のOAuth 2.0フローでは、エンドユーザーは検証のために認可サーバーにリダイレクトされます。PARでは、エンドユーザーがリダイレクトされる前に、要求パラメーターが認可要求の初めに検証されます。リダイレクトされたユーザーにエラーページを表示するのは避けましょう。

PARは、バックチャネルでも認可要求を渡します。フロントチャネル通信は、追加されたHTTPSクエリパラメーター（GET、POST）を介して、ブラウザーなどの仲介役を使用します。メッセージは直接送信されません。バックチャネル通信は、認可されたバックエンド要求の本文で渡されるため、より直接的なアプローチができます。

プッシュ認可要求は、バックチャネルを介して送信されることから、次のことがいえます。

• 認可サーバーは要求の送信元を信頼することができ、要求はエンドユーザーによって変更されていない。
• 要求の詳細はブラウザーバーや履歴に公開されておらず、プライバシーが過程のこの地点で保護される。
• URLの長さに関する制限は強制ではない。

​

制限事項

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

​

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

​

要件

PARエンドポイントへの呼び出しを行うには、以下の操作が必要です。

• 要求のコンテンツタイプをapplication/x-www-form-urlencodedに設定する。
• 渡されるすべてのパラメーターに文字列を使用する。
• アプリケーション認証メソッドの追加パラメーターを要求に含める。機密クライアントのみがPARをサポートしているため、アプリケーション認証メソッドとして使用できるのはクライアントシークレット、秘密鍵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エンドポイントに渡されます。
• 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
 }

​

レート制限

エッセンシャル、プロフェッショナル、エンタープライズの運用テナントでは、PARエンドポイントへの呼び出しは、標準認証APIレート制限に含まれています。詳細については、「レート制限の構成」を参照し、サブスクリプションタイプをクリックしてください。次に、［Authentication API］ をクリックします。

​

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

アプリケーションは、認可要求の/oauth/parエンドポイントから返されたrequest_uriの値を使用し、ユーザーエージェントを認可エンドポイントにリダイレクトします。request_uriパラメーターの詳細については、「プッシュ認可要求（PAR）を構成する」をお読みください。

以下の例では、次の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）を構成する