MS_OIDCRequestObject

OpenID Connect - Requestオブジェクト

• 戻る（OpenID Connect）
  • OpenID Connect - Requestオブジェクト
  • JWT Secured Authorization Request (JAR)
  • JARM

概要

Final を参照して記述。

• Authorization Request に署名および暗号化を可能にする。
• 具体的には、OAuthやOpenID Connectの
  パラメタ群を JWTにして送信する。

補足（なぜ必要か）: 通常の認可リクエストは
URL のクエリ パラメタとして、ブラウザ経由で送られる。
このため、

問題	内容
改ざん	ブラウザ上のマルウェアが scope や redirect_uri を書き換えられる
送信者が不明	Authorization Server は「本当にその Client からか」を確認できない
盗み見	履歴・ログ・Referer に残る

Request オブジェクトは、パラメタ群を1 つの署名済み JWT に
まとめることでこれを解決する。
FAPIが「メッセージ自体の認証が無い」と指摘した問題への回答である。

詳細

（Client から JWTを送信するという意味では、）
JWT bearer token authorization グラント種別の
亜種的仕様。

サポート

• Discoveryのパラメタでサポート状況を確認できる。
  • request_parameter_supported
  • request_uri_parameter_supported
• 要求をサポートしていない場合、それぞれ
  request_not_supported / request_uri_not_supported エラーを返す。

パラメタ

Request オブジェクトを利用する場合、

• request, request_uri パラメタに指定する。
• 他のパラメタを送信するケースがある。
  • 送信する可能性のあるパラメタ
    • response_type, client_id（OAuth 2.0 で必須）
    • scope="* openid *"（OIDCで必須）
    • state, nonce 等（可変パラメタ対応）
  • この場合、Request オブジェクト内のパラメタと重複しても良い
    （重複は一致すること。実際使用するのは Request オブジェクト側）。

フォーマットとコンテンツ

概要

• url セーフな JWTである必要があるが、
  署名および暗号化のアルゴリズムは任意
  • none も可
  • Discovery で確認
• iss と aud が必要で、ID トークンと逆になる。

補足（iss / aud が逆になる意味）: 方向が逆なので、
誰が誰に向けて発行したかも逆になる。

	発行者 (iss)	対象 (aud)
ID トークン	Authorization Server	Client
Request オブジェクト	Client	Authorization Server

つまり Request オブジェクトは
「Client が自分で署名して Authorization Server に渡す JWT」であり、
これ自体がクライアント認証の役割も果たしうる。
FAPI Part 2が認可エンドポイントでの
クライアント認証として Request オブジェクトを挙げているのはこのためである。

ペイロードの例

{
 "iss": "s6BhdRkqt3",
 "aud": "https://server.example.com",
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.org/cb",
 "scope": "openid",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "max_age": 86400,
 "claims": {
   "userinfo": {
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null
   },
   "id_token": {
     "gender": null,
     "birthdate": {"essential": true},
     "acr": {"values": ["urn:mace:incommon:iap:silver"]}
   }
 }
}

補足（alg: none を許すのは危険）: 「署名および暗号化の
アルゴリズムは任意（none も可）」という仕様上の緩さは、
JWAで述べた alg: none 問題そのものである。

署名しない Request オブジェクトは、
URL パラメタで送るのと保護レベルが変わらない（むしろ検証を
素通りさせる分だけ危うい）。
FAPIや JARでは none が禁止され、
PS256 / ES256 に限定されている。

送信方法

requestパラメタ

https://server.example.com/authorize?
   response_type=code%20id_token
   &client_id=s6BhdRkqt3
   &scope=openid
   &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
   &request=＜Requestオブジェクト（JWT）＞

request_uriパラメタ

• 512 ASCII 文字以内
• Authorization Server からのアクセスに限定する。
  • ライフタイムに応じた適切なエントロピー、
  • 若しくは、なんらかのアクセスコントロールの実施。

https://client.example.org/request.jwt#GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

※ URI フラグメントは、キャッシュに使用するペイロードの
SHA-256 ハッシュの Base64URL 値

https://server.example.com/authorize?
   response_type=code%20id_token
   &client_id=s6BhdRkqt3
   &scope=openid
   &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
   &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt%23GkurKx...

補足（request_uri は PAR へ発展した）: request_uri 方式は
「URL が長くなる問題」を解決したが、別の課題を生んだ。

課題	内容
Client が公開サーバーを持つ必要	request.jwt をホストしなければならない
SSRF のリスク	Authorization Server が任意の URL を取りに行く
事前登録が要る	取りに行く先を制限するため

これを解決したのが PAR（Pushed Authorization Requests、RFC 9126） である。

• Client が Authorization Server に直接 POST する（バックチャネル）。
• Authorization Server が request_uri を発行して返す。

方向が逆になることで、Client 側のホスティングも SSRF の懸念も消える。
FAPI 2.0 では PAR が必須になっている。

なお、元 Wiki には PAR の独立したページが存在しないため、
ここでは RFC を直接参照する。
RFC 9126: https://datatracker.ietf.org/doc/html/rfc9126

参考

• OpenID Connect Core 1.0 > 6. Passing Request Parameters as JWTs
  https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#JWTRequests

関連

• JWT bearer token authorization グラント種別
  Client から OP(IdP/STS) に JWTを送るという意味では似ている。
• JWT Secured Authorization Request (JAR)
  別途、仕様に書き起こしたもの（FAPI2でも使用するので）。

---

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth