OAuth2.0 PAR(Pushed Authorization Requests)の概要

PARの目的

RFC6749の認可エンドポイントはブラウザ経由(フロントチャネル)で呼び出されることを前提としています。
そのため以下のような課題があります。

• クライアント認証が行えない
• 基本的にGETメソッドで呼び出される
  • パラメータがブラウザに露出する
  • パラメータの改竄のリスクがある
  • URLが非常に長くなる可能性がある

これらの課題を解決するため、認可リクエストのパラメータを事前にバックチャネルで送信する仕組みとしてPAR (Pushed Authorization Requests) が定義されました。

PAR Endpointの使い方

PARエンドポイントの使い方を起点にPARを含むフローを説明します。
PAR Endpointへのリクエストサンプルです。
元は認可エンドポイントに送るものだったresponse_typeやstateなどの値をここでまとめてPAR Endpointへ送ってしまいます。¹

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

response_type=code&state=af0ifjsldkj&client_id=CLIENT1234
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information

PAR Endpointのレスポンスサンプルです。
request_uri(redirect_uriじゃないですよ)の末尾が乱数になっており、この値がキーとしての役目を持っていることがわかります。
この値が先ほど送ったパラメータ群とサーバー内で紐づいています。

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache, no-store

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

その後認可エンドポイントを叩きます。
前段のPAR Endpointであらかたのパラメータを送ってしまっているため、ここではclient_idとrequest_uriを送信するだけでよいです。

GET /authorize?client_id=CLIENT1234
  &request_uri=urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c

これで認可エンドポイントへのリクエストが完了しました。以降の処理はPARを使わないフローと同様です。

PAR Endpointの利用を含んだフロー

PAR Endpointを利用する場合の認可コードフロー図です。

1. 認証のためのパラメータ等、RFC6749では定義されないパラメータを指定することもできます。 ↩