For Authlete 2.x documentation, see 2.x version.
はじめに
RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) は、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 をバックエンドとして利用できます。この API は他のエンドポイントと同じ設計方針に基づいており、認可サーバーはクライアントからプッシュされた認可リクエストを Authlete へそのまま転送するだけで済みます。
request_uri が含まれており、クライアントは認可リクエストを行う際にこれを利用できます。
リクエストとレスポンスの例
クライアントから PAR EP へプッシュされる認可リクエストの内容は、通常の認可エンドポイントへのリクエストと似ていますが、クライアントが POST メソッドと application/x-www-form-urlencoded メディアタイプを用いて認可リクエストを送信する点が異なります。- リクエスト
- レスポンス
request_uri を用いて、クライアントはユーザーエージェント経由で認可サーバーへ認可リクエストを送信します。このリクエストを受け取った認可サーバーは、次のように Authlete の /auth/authorization API へリクエストを行います。
Authlete での PAR 設定
認可サーバーの PAR エンドポイントのバックエンドとして Authlete サービスを構成するには、Authlete 管理コンソールにログインし、対象の Authlete サービスの「サービス設定」を開きます。 「プッシュ式認可リクエスト（PAR）」タブでは、次の設定が可能です。- 「PARを必須にする」オプションを切り替えることで、すべてのクライアントに対して PAR の利用を必須とするかどうかを指定します。
- プッシュされた認可リクエストの有効期間（秒単位）を設定します。
- 対象クライアントの「クライアント設定」を開きます。
- 「エンドポイント」>「一般」>「プッシュ式認可リクエスト」へ移動します。
- 「PARを必須にする」スイッチを切り替えて有効にします。
クライアント認証
認可サーバーは PAR EP においてクライアントを認証する場合があります。Authlete では、トークンエンドポイント向けの認証方式の設定を PAR EP にも適用します。その仕組みについては、次の記事で説明しています。 「サービス設定」の「トークン」タブでは、トークンエンドポイントがサポートする「クライアント認証方式」を設定できます。要件に応じて、PRIVATE_KEY_JWT や TLS_CLIENT_AUTH などの方式を選択してください。
設定手順は次のとおりです。
- 「サービス設定」>「エンドポイント」>「トークン」へ移動します。
- 「サポート可能なクライアント認証方式」で、必要な認証方式を選択します。
- 「変更を保存」をクリックします。
/pushed_auth_req API へリクエストを行います（以下のスニペットを参照）。