Open3

RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)

yapooyapoo

RFC 9101 - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)

概要

RFC 6749 では認可エンドポイントではクエリパラメータによって諸々の指定が行われるが、このインターフェースには以下の問題がある。

  • パラメータが保護されておらず、データの完全性を持たない (TLS は一般にロードバランサーや CDN などで一旦終端されるので TLS はデータの保護に対しては部分的な解決策にしかならない)
  • 認可エンドポイントの client_id の認証を行えない
  • ユーザーエージェントを介したリクエスト・レスポンスはモニタリング可能である

そこで、認可エンドポイントのリクエストパラメータを JWT (JWS または暗号化が必要な場合は JWE) で行うことによって上記の問題を解決する。

これは OpenID Connect Core の Section 6 で定義されたものと同様の仕様だが、ところどころ衝突する点があるようだ [1]

脚注
  1. https://qiita.com/TakahikoKawasaki/items/d52ce91866ae0dcc2ff7 ↩︎

yapooyapoo

Request Object

認可エンドポイントのリクエストのために用いられる JWT を Request Object という。Request Object は JWS か (暗号化が必要な場合には) JWE であり、以下の注意点がある

  • iss クレームを含むべきである [1]
  • aud クレームを含むべきで、この値は RFC 8414 ( OAuth 2.0 Authorization Server Metadata) で定義される issuer に等しい。
  • 認可エンドポイントのパラメータをクレームとして持つ。ここでキーと String としての値は JSON String で数値としての値は JSON Number でなければならない。

以下は Requeset Object の例として Section 4 に記載されているものである

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

このペイロードの JSON は以下である。このように OAuth 2.0 として定義されていない拡張パラメータを含んでいても良い。

{
 "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
}
脚注
  1. これは client_id と同じでなくても良いらしいが、このクレームを持たせる目的はよくわからない。 ↩︎

yapooyapoo

認可エンドポイント

本仕様では認可エンドポイントに下記のパラメータを導入する。本仕様を用いる場合、requestrequest_uri は必ずどちらか一方のみを指定する。

parameter description
request JWT を直接リクエストに含める場合にはここで JWT を指定する
request_uri JWT への参照 (絶対 URI か URN) を指定する
client_id 必須。Request Object の client_id クレームと同じ値でなければならない[^1]

Request Object とクエリパラメータによるパラメータ指定が同時に用いられていてもよいが、その場合も認可サーバーは Request Object の値のみを用いなければならない。

request_uri で絶対 URI が指定された場合認可サーバーはこの URI に GET リクエストを送ることで Request Object を取得する。このときは Content-Type application/oauth-authz-req+jwt として返却される。