RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
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]。
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
}
-
これは
client_id
と同じでなくても良いらしいが、このクレームを持たせる目的はよくわからない。 ↩︎
認可エンドポイント
本仕様では認可エンドポイントに下記のパラメータを導入する。本仕様を用いる場合、request
と request_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
として返却される。