> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  ハイリーレギュレーテッドアイデンティティ機能を使用するには、エンタープライズプランとハイリーレギュレーテッドアイデンティティアドオンが必要です。詳細については、「[Auth0の価格設定](https://auth0.com/pricing/)」を参照してください。
</Callout>

[Pushed Authorization Request（PAR）](https://datatracker.ietf.org/doc/html/rfc9126)は、認可サーバーに対して、認可要求の内容をプッシュ（直接送信）するバックエンドプロトコルです。PARは、高付加価値なAPIの保護を目的とした[Financial-Grade API (FAPI) Security Profile 1.0](https://openid.net/specs/openid-financial-api-part-2-1_0.html)の技術コンポーネントです。

## 仕組み

PARでは、アプリケーションは<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=oath2" tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集の表示">OAuth 2.0</Tooltip>認可要求のパラメーターを、認可サーバーのPARエンドポイントに直接プッシュできます **(1)** 。これに対して、認可サーバーは要求URIの値`request_uri`を送信し **(2)**、`/authorize`エンドポイントを呼び出すときに使用します **(3)**。`request_uri`は、`/par`エンドポイントで保存された認可要求への参照であるため、これらの要求は公開されません **(4)**。詳細については、「[プッシュ認可要求を構成する](/docs/ja-jp/get-started/applications/configure-par)」をお読みください。

<Frame>
  <img src="https://mintcdn.com/docs-dev-docs-event-stream-action-templates/ZqABYvyPOuGZRvBz/docs/images/ja-jp/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/601db8966fea11c30acbff6d9213b6a0/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png?fit=max&auto=format&n=ZqABYvyPOuGZRvBz&q=85&s=89fd6718d65a48d5243596d831987051" alt="null" width="1500" height="1000" data-path="docs/images/ja-jp/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/601db8966fea11c30acbff6d9213b6a0/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png" />
</Frame>

## メリット

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

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

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

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

## 制限事項

* 要求ペイロードの最大サイズは10 KBです。
* パブリックアプリケーションは現在サポートされていません。詳細については、「[パブリックアプリケーションと機密アプリケーション](/docs/ja-jp/get-started/applications/confidential-and-public-applications)」をお読みください。

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

### 要件

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

* 要求のコンテンツタイプを`application/x-www-form-urlencoded`に設定する。
* 渡されるすべてのパラメーターに文字列を使用する。
* アプリケーション認証メソッドの追加パラメーターを要求に含める。機密クライアントのみがPARをサポートしているため、[アプリケーション認証メソッド](https://auth0.com/docs/api/authentication#authentication-methods)として使用できるのはクライアントシークレット、秘密鍵<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-3" href="/docs/ja-jp/glossary?term=json-web-token" tip="JSON Web Token（JWT）: 二者間のクレームを安全に表現するために使用される標準IDトークン形式（および多くの場合、アクセストークン形式）。" cta="用語集の表示">JWT</Tooltip>、およびmTLSです。アクセストークンを取得するときは、`/token`エンドポイントに同じアプリケーション認証メソッドを使用する必要があります。

### 対応しているパラメーター

保存・処理されるPARエンドポイントは以下のものに限られます。

* 標準OAuth 2.0パラメーターと該当の拡張子（認可ポイントで認識される）
* 接頭辞が`ext-`のカスタム認可パラメーター（最大10個）

PARは、追加のカスタム認可パラメーターを無視します。カスタム認可パラメーターは、[Auth0 Actions](/docs/ja-jp/customize/actions)と[Logs](/docs/ja-jp/deploy-monitor/logs)では使用できません。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Actionsでカスタムの認可パラメーターを使用する場合は、「`ext-`」のプレフィックスを付けなければなりません。このプレフィックスがないパラメーターは使用できません。
</Callout>

### PAR要求の例

```bash lines theme={null}
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秒の有効期限は静的な値で、設定することはできません。

```lines theme={null}
HTTP/1.1 201 Created
 Content-Type: application/json

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

### レート制限

エッセンシャル、プロフェッショナル、エンタープライズの運用テナントでは、PARエンドポイントへの呼び出しは、標準認証APIレート制限に含まれています。詳細については、「[レート制限の構成](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)」を参照し、サブスクリプションタイプをクリックしてください。次に、**［Authentication API］** をクリックします。

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

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

以下の例では、次のHTTP要求を行うようユーザーエージェントに指示を出しています。

```lines theme={null}
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）を構成する](/docs/ja-jp/get-started/applications/configure-par)