Skip to main content
For Authlete 2.x documentation, see 2.x version.

はじめに

RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) は、OAuth2 フレームワークにおける強力なセキュリティ拡張のひとつです。これは、クライアントが認可サーバーに対して、認可リクエストを従来の方法(ブラウザリダイレクトによる間接通信)で送信する前に、その内容を「プッシュ」(直接送信)できるようにするものです。 PAR 仕様が定義するのは、認可リクエストの内容の事前送信を受けつけるエンドポイント (PAR EP) です。PAR EP は、リクエストを受信すると、識別子 (request_uri) を含むレスポンスを返却します。その返却された識別子を、クライアントは認可リクエストに含めます。 認可リクエストの内容を直接送信し、従来の間接通信による認可リクエストと分離することにより、セキュリティ強化の選択肢が広がります。たとえば SPA (Single Page Application) では、サーバーサイドで認可リクエストの内容を生成・送信し、ブラウザを経由する認可リクエスト自体には詳細を含めないようにできます。またモバイルアプリケーションにおいても、ブラウザに認可リクエスト処理を引き継ぐ前に、認可リクエストの内容を生成・送信できるようになります。 本記事では、Authlete における PAR のサポートの概要と、設定方法について記述します。

PAR EP の実装

PAR をサポートするためには、認可サーバー(OIDC における OP)に PAR EP を実装し、Authlete の PAR サポートを設定する必要があります。 認可サーバーの PAR  EP のバックエンドとなるのは Authlete の /pushed_auth_req API です。この API は、他の OAuth/OIDC エンドポイントに対応する Authlete API と同様に設計されています。認可サーバーは、クライアントから受信した「認可リクエストの内容」を、そのまま Authlete に転送すれば良いのです。\ puahed-authorization-requests_ja PAR を用いた認可コードフロー Authlete の /pushed_auth_req API は、/auth/authorization API と同様のペイロードと、それに加えてクライアント認証の情報も受けつけます。そして認可サーバーに、クライアントに返却されることになるレスポンスの内容 (responseContent) を提供します。レスポンスの内容には request_uri が含まれています。クライアントはこの request_uri を取り出し、認可リクエストに指定することになります。

リクエストとレスポンスの例

クライアントが PAR EP にプッシュする認可リクエストの内容は、従来の認可エンドポイントに対する認可リクエストの内容と同じです。異なるのは、クライアントが POST メソッドかつ application/x-www-form-urlencoded メディアタイプを用いて、認可リクエストの内容を送信する点です。
以下は認可サーバーと Authlete の /pushed_auth_req API との間のやりとりの例です。PKCE を含む認可コードフローの要求を、クライアントが PAR EP に事前送信しています。Authlete は、action として “CREATED”、そして requestUri を含むレスポンスを返却しています。これは、Authlete が認可リクエストの内容を受けつけ、 その識別子として requestUri を生成したことを示しています。同時に Authlete は responseContent を返却しています。認可サーバーはこの responseContent の値(コンテンツ)を、PAR EP からのレスポンスとして、クライアントに返却することになります。
  • リクエスト
  • レスポンス
クライアントは PAR EP から返却された request_uri  の値を用いて、認可サーバーに対し、ユーザーエージェントを経由して認可リクエストを送信します。その認可リクエストを受信した認可サーバーは、Authlete の  /auth/authorization API に対して、以下のようにリクエストを送信します。
Authlete は、従来の認可リクエストを処理する場合と同様、チケットを生成・返却します。Authlete のチケットについては関連記事 をご参照ください。

Authlete の PAR 設定

管理者はサービスオーナーコンソールを用いて、Authlete サービスが認可サーバーの PAR EP のバックエンドとしてどのように機能するかを設定できます。具体的には、プッシュされた認可リクエストの内容の有効期間と、PAR の使用をすべてのクライアントに必須化するかどうかです。 Screen_Shot_2021-07-26_at_20 サービスレベルでの PAR 設定 PAR の必須化は、Authlete サービス全体としてはそのように設定していない場合でも、クライアント単位で個別に有効化できます。開発者コンソールの「認可」タブにある、以下の設定項目を用います。Screen_Shot_2021-07-26_at_21 特定のクライアントに PAR の使用を必須化するかどうかの設定

クライアント認証

PAR EP において、認可サーバーはクライアント認証を行うかもしれません。その際のクライアント認証方法の設定はトークンエンドポイントと共通です。詳細は以下の記事をご参照ください。 クライアント認証方法の設定は開発者コンソールの「認可」タブにあります。\ Screen_Shot_2021-07-28_at_20 トークンエンドポイントと PAR エンドポイントのクライアント認証方法 CLIENT_SECRET_BASIC の場合、PAR EP は HTTP Basic 認証を用いてクライアント認証を行うことになります。 認可サーバーは Authlete の /pushed_auth_req API を呼び出す際に、クライアントから提示されたクレデンシャルを、“clientId” と “clientSecret” を用いて送信します。(以下は抜粋です)
クライアント証明書を用いてクライアント認証を行うよう設定した場合には、認可サーバーから Authlete へのリクエストは以下のようになります。
PKI に基づく TLS_CLIENT_AUTH、すなわち Authlete がクライアントの証明書チェインを検証する場合には、認可サーバーから Authlete へのリクエストは以下のようになります。