> ## Documentation Index > Fetch the complete documentation index at: https://developers.authlete.com/llms.txt > Use this file to discover all available pages before exploring further. # Pushed Authorization Requests (PAR) > Authlete における RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) の設定方法について説明します。 For **Authlete 2.x** documentation, see [2.x version](/ja/v2/configuration-reference/endpoints/pushed-authorization-requests-par). ## はじめに [RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR)](https://www.rfc-editor.org/rfc/rfc9126.html) は、OAuth 2.0 フレームワークにおいて最も影響の大きいセキュリティ強化の一つです。この仕様により、クライアントは認可リクエストの内容を、従来のようにユーザーエージェント経由で送信する代わりに、あらかじめ認可サーバーへ「プッシュ」（直接送信）できるようになります。 PAR 仕様では、認可リクエストの内容を受け付ける新しいエンドポイント（PAR EP）が定義されています。PAR EP は識別子（request\_uri）を返却し、クライアントは後続の認可リクエストにその値を含めることができます。認可リクエスト内容の受け渡しを認可リクエスト本体から分離することで、セキュリティを強化する新たな選択肢が生まれます。たとえば、SPA（シングルページアプリケーション）では、認可リクエストの詳細をブラウザーに一切開示することなく、サーバーサイドに認可リクエスト内容の生成を任せることができます。また、モバイルアプリでは、認可リクエスト内容を生成・送信してからブラウザーへ引き渡すことができます。本記事では、Authlete における PAR サポートの概要と、その有効化手順について説明します。 *** ## PAR EP の実装 PAR をサポートするには、認可サーバー（OIDC の文脈では OP）に PAR EP を実装し、Authlete で PAR の設定を行う必要があります。認可サーバーの PAR EP は、Authlete の [/pushed\_auth\_req](/api-reference/pushed-authorization-endpoint/process-pushed-authorization-request) API をバックエンドとして利用できます。この API は他のエンドポイントと同じ設計方針に基づいており、認可サーバーはクライアントからプッシュされた認可リクエストを Authlete へそのまま転送するだけで済みます。

*プッシュ型認可リクエストを用いた認可コードフロー* Authlete の [/pushed\_auth\_req](/api-reference/pushed-authorization-endpoint/process-pushed-authorization-request) API は、[/auth/authorization](/api-reference/authorization-endpoint/process-authorization-request) API と同じペイロードに加えて、クライアント認証を必要とします。[/pushed\_auth\_req](/api-reference/pushed-authorization-endpoint/process-pushed-authorization-request) API は、クライアントへ返送するためのプッシュ型認可レスポンスの内容（responseContent）を提供します。この内容には `request_uri` が含まれており、クライアントは認可リクエストを行う際にこれを利用できます。 ### リクエストとレスポンスの例クライアントから PAR EP へプッシュされる認可リクエストの内容は、通常の認可エンドポイントへのリクエストと似ていますが、クライアントが POST メソッドと application/x-www-form-urlencoded メディアタイプを用いて認可リクエストを送信する点が異なります。 ``` POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded response_type=code& client_id=3280859750204& redirect_uri=https%3A%2F%2Fmobile.example.com%2Fcb& code_challenge=W78hCS0q72DfIHa...kgZkEJuAFaT4& code_challenge_method=S256 ``` 以下のリクエスト例は、認可サーバーと Authlete の [/pushed\_auth\_req](/api-reference/pushed-authorization-endpoint/process-pushed-authorization-request) API とのやり取りを示しています。この例における認可リクエストの内容は PKCE を用いた認可コードフローを開始するものであり、クライアントによって用意されるべきものです。 Authlete からのレスポンスはアクション "CREATED" と requestUri であり、認可リクエストが requestUri の値を識別子として登録されたことを意味します。Authlete は responseContent も生成します。この値は、PAR EP からクライアントへのプッシュ型認可レスポンスとして利用されることを想定しています。 * リクエスト ``` curl --request POST 'https://us.authlete.com/api//pushed_auth_req' \ --header 'Authorization: Bearer ************' \ --header 'Content-Type: application/json' \ --data '{ "parameters": "response_type=code& client_id=3280859750204& redirect_uri=https%3A%2F%2Fmobile.example.com%2Fcb& code_challenge=W78hCS0q72DfIHa...kgZkEJuAFaT4& code_challenge_method=S256", "clientId": "3280859750204"}' ``` * レスポンス ``` { "resultCode": "A245001", "resultMessage": "[A245001] Successfully registered a request object for client (3280859750204), URI is urn:ietf:params:oauth:request_uri:UymBrux4ZEMrBRKx9UyKyIm98zpX1cHmAPGAGNofmm4.", "action": "CREATED", "requestUri": "urn:ietf:params:oauth:request_uri:UymBrux4ZEMrBRKx9UyKyIm98zpX1cHmAPGAGNofmm4", "responseContent": "{\"expires_in\":600,\"request_uri\":\"urn:ietf:params:oauth:request_uri:UymBrux4ZEMrBRKx9UyKyIm98zpX1cHmAPGAGNofmm4\"}" } ``` PAR EP から返却された `request_uri` を用いて、クライアントはユーザーエージェント経由で認可サーバーへ認可リクエストを送信します。このリクエストを受け取った認可サーバーは、次のように Authlete の /auth/authorization API へリクエストを行います。 ``` curl --request POST 'https://us.authlete.com/api//auth/authorization' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ************' \ --data '{ "parameters": "client_id=3280859750204& request_uri=urn:ietf:params:oauth:request_uri:UymBrux4ZEMrBRKx9UyKyIm98zpX1cHmAPGAGNofmm4" }' ``` Authlete からのレスポンスは通常の認可リクエストと同じです。チケットが生成されます。詳細は [Authlete のチケットに関する説明](/ja/configuration-reference/endpoints/ticket-parameter-in-authorization-endpoint)をご参照ください。 *** ## Authlete での PAR 設定認可サーバーの PAR エンドポイントのバックエンドとして Authlete サービスを構成するには、Authlete 管理コンソールにログインし、対象の Authlete サービスの「サービス設定」を開きます。「プッシュ式認可リクエスト（PAR）」タブでは、次の設定が可能です。 * 「PARを必須にする」オプションを切り替えることで、すべてのクライアントに対して PAR の利用を必須とするかどうかを指定します。 * プッシュされた認可リクエストの有効期間（秒単位）を設定します。必要な変更を行い、「変更を保存」をクリックして設定を適用します。

*サービスレベルでのプッシュ型認可リクエストの設定* Authlete サービスが PAR を必須とするよう構成されていない場合でも、特定のクライアントに対して PAR を必須にできます。これを有効にするには、次の手順を行います。 1. 対象クライアントの「クライアント設定」を開きます。 2. 「エンドポイント」>「一般」>「プッシュ式認可リクエスト」へ移動します。 3. 「PARを必須にする」スイッチを切り替えて有効にします。この設定により、サービスレベルの構成を上書きして、当該クライアントに PAR の利用を強制できます。

*特定のクライアントにプッシュ型認可リクエストを強制するフラグ* *** ## クライアント認証認可サーバーは PAR EP においてクライアントを認証する場合があります。Authlete では、トークンエンドポイント向けの認証方式の設定を PAR EP にも適用します。その仕組みについては、次の記事で説明しています。 * [クライアント認証の設定](/ja/configuration-reference/endpoints/configuring-client-authentication) 「サービス設定」の「トークン」タブでは、トークンエンドポイントがサポートする「クライアント認証方式」を設定できます。要件に応じて、`PRIVATE_KEY_JWT` や `TLS_CLIENT_AUTH` などの方式を選択してください。設定手順は次のとおりです。 1. 「サービス設定」>「エンドポイント」>「トークン」へ移動します。 2. 「サポート可能なクライアント認証方式」で、必要な認証方式を選択します。 3. 「変更を保存」をクリックします。これらの設定により、クライアントがトークンエンドポイントへアクセスする際の認証方法が定義されます。

*クライアントごとのトークンエンドポイントおよび PAR エンドポイントにおけるクライアント認証方式* 認証方式が CLIENT\_SECRET\_BASIC の場合、クライアントは HTTP Basic 認証を用いて PAR EP で認証されます。認可サーバーは、クライアントから提示された資格情報を "clientId" 属性と "clientSecret" 属性として用い、Authlete の `/pushed_auth_req` API へリクエストを行います（以下のスニペットを参照）。 ``` curl --location --request POST 'https://us.authlete.com/api//pushed_auth_req' \ --header 'Authorization: Bearer c2JwsOb6ID8iCC5DN*********LWtv' \ --header 'Content-Type: application/json' \ --data-raw '{ "parameters": "response_type=code%20id_token&client_id=3280859750204&redirect_uri=https%3A%2F%2Fserver.example.com%2Fcb&state=SOME_VALUE_ABLE_TO_PREVENT_CSRF&scope=openid&nonce=SOME_VALUE_ABLE_TO_PREVENT_REPLAY_ATTACK&code_challenge=GyeodZxSpq0iyjNbEQE6N96MxomMXYpYUkfuEpvQ3Js&code_challenge_method=S256", "clientId": "3280859750204", "clientSecret": "qfd0ScLHhD**************YDg" }' ``` クライアントがクライアント証明書ベースの認証方式向けに構成されている場合、リクエストは次のようになります。 ``` curl --location --request POST 'https://us.authlete.com/api//pushed_auth_req' \ --header 'Authorization: Bearer c2JwsOb6ID8iCC5DN*********LWtv' \ --header 'Content-Type: application/json' \ --data-raw '{ "parameters":"response_type=code&client_id=....", "clientId":3282602314604, "clientCertificate":"\n-----BEGIN CERTIFICATE-----\nMIICnDCCAYSgAwIBAgIGAXqsMta0MA0GCSqGSIb3DQEBCwUAMA8xDTALBgNVBAMM\nBGtleTEwHhcNMjEwNzE1MjIwNDEwWhcNMjIwNTExMjIwNDEwWjAPMQ0wCwYDVQQD\nDARrZXkxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAh517rALrL+I9\npvOpCVr9wuJ/TE3l3CndvE9oRrU2BpBYSn0LVnIT6anKgrYSJNP/YOkgHqUQQIoq\n0j7Uv7fiYL02OuAuVouOP3pxC1QiRGNInZkmYVJ0EsNz8Gft3JW7A9pUHc/Sx0P1\nTbN1hL9J5auasCNjUhd3GCB7bEJeIlez066qkUeZR/Jtpqdh9TVJrnBjEiihrcwL\nlixo4G5Y2Tg9vpjOCKgoL1tni6wbxY64BzksF2y10OEfvcwacmLBsMxHhN3l0qU2\nnbKbYKb2R0xRq8DU5woG0Rkbi5z6FRF4DLzpjig6vk6ENjwenHFYt8XMhulmSdnX\nGvDe2/BWYQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQABRsoLK5hn5DesBpnDCBfq\nZnyMiWyUbh8qmIhO5Ta6Hq/AeUSM16gqJqBsLQm6UllfsW30Qn9EwkCMG1Fb4g8t\n5TVigtvtVcTkn3H2Ib6EhtsB5Evs1U273W5Z/y7QUDrS2TahraKNKK2k81UbHhZf\nY1qyDMTK1+a+EAcuUaFOPsOzZo3Yxa2GDXQ8ZjHwk4E7tIri953P66gGHC3GNTy\n92hrXw8KgoIXJXKyZ5WeyziTIfAypnlI6EzUU\n-----END CERTIFICATE-----" }' ``` PKI 認証を用いた TLS\_CLIENT\_AUTH の場合（Authlete がルート CA のリストに対してクライアント証明書チェーンを検証できるケース）、認証は次のリクエストのようになります。 ``` curl --location --request POST 'https://us.authlete.com/api//pushed_auth_req' \ --header 'Authorization: Bearer c2JwsOb6ID8iCC5DN*********LWtv' \ --header 'Content-Type: application/json' \ --data '{ "parameters":"response_type=code&client_id=3289644915401&...", "clientId":3289644915401, "clientCertificate":"\n-----BEGIN CERTIFICATE-----\nMIIDmzCCAoOgAwIBAgI.....ftMPIhU1ocI0Uh9ObkPq5atK0lx\n39OTMXLj1kHxlf3RnoRo\n-----END CERTIFICATE-----", "clientCertificatePath":["\n-----BEGIN CERTIFICATE-----\nMIIE3TCCAsWgAwI.....9HEtxsOeIDWmILz453xtSBdorV7rN7QcEK6Hd62czruZtk/ItPjQMnB1moBT3d\n5g==\n-----END CERTIFICATE-----", "\n-----BEGIN CERTIFICATE-----\nMIIFuDCCA6CgAwI.....FRVZqvemtV0gZM0C3tkDBQzGsb/KW\nnFWbOABBQequSMJN0MjWd+fkiDZAJq/X0Gw==\n-----END CERTIFICATE-----"]}' ```