RFC 9101: OAuth 2.0 認可フレームワーク: JWTで保護された認可リクエスト (JAR)

RFC 9101	OAuth JAR	2021年8月
Sakimura, et al.	標準化過程	[ページ]

概要

RFC 6749で説明されているOAuth 2.0の認可リクエストは、クエリパラメータのシリアライズを利用している。これは、認可リクエストのパラメータがリクエストのURIにエンコードされ、Webブラウザなどのユーザーエージェントを通じて送信されることを意味する。実装は容易である一方で、 a) ユーザーエージェントを介した通信は完全性が保護されず、そのためパラメータが改ざんされる可能性がある、b) 通信元が認証されない、そして c) ユーザーエージェントを介した通信が監視される可能性がある、ということを意味する。これらの弱点により、このプロトコルに対する複数の攻撃が現在までに提示されている。¶

本文書は、代わりにリクエストパラメータを JSON Web Token (JWT)で送信する機能を導入する。これにより、リクエストを JSON Web Signature (JWS)で署名し、JSON Web Encryption (JWE)で暗号化できるため、認可リクエストの完全性、送信元認証、および機密性の特性が得られる。リクエストは値として、または参照として送信できる。¶

1. はじめに

OAuth 2.0 [RFC6749]における認可リクエストは、クエリパラメータのシリアライズを利用しており、通常はWebブラウザなどのユーザーエージェントを通じて送信される。¶

例えば、パラメータresponse_type、client_id、state、および redirect_uriは、リクエストのURIにエンコードされる:¶

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

実装は容易である一方で、URIへのエンコードでは、機密性および完全性保護を提供するためのアプリケーション層セキュリティを使用できない。 TLSは、クライアントとユーザーエージェントの間、およびユーザーエージェントと認可サーバーの間で通信セキュリティを提供するために使用されるが、TLSセッションはユーザーエージェントで終端される。さらに、TLSセッションは何らかのミドルボックス（ロードバランサーなど）で途中終端される可能性がある。¶

その結果、[RFC6749]の認可リクエストには、次のような欠点がある:¶

(a): ユーザーエージェントを介した通信が完全性保護されておらず、そのためパラメータが改ざんされ得る（完全性保護の失敗）;¶
(b): 通信元が認証されない（送信元認証の失敗）;¶
(c): ユーザーエージェントを介した通信が監視され得る（閉じ込め/機密性の失敗）。¶

こうした本質的な弱点により、リダイレクトURIの書き換えなど、このプロトコルに対する複数の攻撃が特定されている。¶

アプリケーション層セキュリティの使用は、これらの問題を軽減する。¶

アプリケーション層セキュリティを使用すると、信頼された第三者がリクエストを準備できるため、クライアントアプリケーションは事前に合意されたものより多くの権限を要求できない。¶

さらに、リクエストを参照として渡すことにより、通信路上のオーバーヘッドを削減できる。¶

JWT [RFC7519]エンコーディングが選択された理由は次のとおりである:¶

(1): OAuthのレスポンス形式として用いられるJSONとの密接な関係¶
(2): テキスト形式であることによる開発者にとっての扱いやすさ¶
(3): XMLと比較した相対的なコンパクトさ¶
(4): 関連する署名および暗号化方式 [RFC7515] [RFC7516]とともに、Proposed Standardとしての開発状況¶
(5): XML SignatureおよびXML Encryptionと比較したJWSおよびJWEの相対的な容易さ。¶

パラメータrequestおよびrequest_uriは、 OAuth 2.0 [RFC6749]フローのための追加の認可リクエストパラメータとして導入される。 requestパラメータは JSON Web Token (JWT) [RFC7519]であり、そのJWT Claims SetにはJSONエンコードされたOAuth 2.0認可リクエストパラメータが含まれる。 RFC 7519とは対照的に、Claims Setの要素はエンコードされたOAuthリクエストパラメータ [IANA.OAuth.Parameters]であり、 IANA管理のJSON Web Token Claims [IANA.JWT.Claims]のうち、特にiss および audなど、ごく少数だけが補足されることに注意すること。 requestパラメータ内のJWTは、JWSを使用して完全性保護され、送信元認証される。¶

JWT [RFC7519]は、参照として認可エンドポイントに渡すことができ、その場合はrequestの代わりに request_uriパラメータが使用される。¶

クエリパラメータの代わりにJWT [RFC7519]をリクエストエンコーディングとして使用することには、複数の利点がある:¶

(a): 完全性保護。リクエストに署名できるため、リクエストの完全性を確認できる。¶
(b): 送信元認証。リクエストに署名できるため、署名者を認証できる。¶
(c): 機密性保護。リクエストを暗号化できるため、TLS接続がどこかの時点で（ユーザーエージェント上およびその手前を含む）終端されても、エンドツーエンドの機密性を提供できる。¶
(d): 収集の最小化。認可リクエストが特定のポリシーに準拠していることを証明する信頼された第三者が、リクエストに署名できる。例えば、リクエストは信頼された第三者によって事前に審査され、要求されたすべての個人データが、エンドユーザーが求めた処理を実行するために厳密に必要であることを確認できる。その後、そのリクエストはその信頼された第三者によって署名される。認可サーバーは署名を検査し、適合状態をエンドユーザーに表示することで、エンドユーザーは認可時にリクエストの正当性について一定の保証を得られる。場合によっては、そのような状況で認可ダイアログを省略することさえ望ましいことがある。¶

参照によるリクエストが有用な場合がいくつかある。例えば次のような場合である:¶

送信されるリクエストのサイズを小さくすることが望ましい場合。アプリケーション層セキュリティを使用すると、特に公開鍵暗号を用いる場合にリクエストのサイズが増加する。¶
クライアントがアプリケーションレベルの暗号処理を行いたくない場合。認可サーバーは、クライアントとの直接通信を通じて認可リクエストを受け付けるエンドポイントを提供できるため、クライアントは認証され、チャネルはTLSで保護される。¶

この機能はOpenID Connect [OpenID.Core]で使用されている。¶

1.1. 要件言語

本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174]で説明されるように解釈される。 ¶

4. リクエストオブジェクト

リクエストオブジェクト（セクション2.1）は、 OAuth 2.0認可リクエストのための認可リクエストパラメータを提供するために使用される。これは、この文書で定義される requestおよび request_uriパラメータを除き、 OAuth 2.0 [RFC6749]認可リクエストの処理に使用されるすべてのパラメータ（拡張パラメータを含む）をMUST含まなければならない。パラメータは、そのオブジェクトのJWT Claimsとして表される。パラメータ名および文字列値はJSON文字列として含められなければならない。リクエストオブジェクトはドメインをまたいで扱われ、閉じたエコシステムの外部で扱われる可能性があるため、 [RFC8259]のセクション8.1に従い、これらのJSON文字列はUTF-8 [RFC3629]を使用してエンコードされなければならない。数値はJSON数値として含められなければならない。リクエストオブジェクトは任意の拡張パラメータを含んでもよい。このJSON [RFC8259] オブジェクトは、 JWT [RFC7519]で定義されるJWT Claims Setを構成する。その後、JWT Claims Setは署名されるか、または署名され暗号化される。¶

署名には、JSON Web Signature (JWS) [RFC7515]が使用される。その結果はJWS署名付きJWT [RFC7519]である。署名される場合、認可リクエストオブジェクトは iss（issuer）およびaud（audience）Claimsをメンバーとして含むべきであり、そのセマンティクスはJWT [RFC7519]仕様で定義されるものと同じである。 audの値は、RFC 8414 [RFC8414]で定義される認可サーバー（AS）の issuerの値であるべきである。¶

暗号化には、JWE [RFC7516]が使用される。署名と暗号化の両方を適用する場合、 JWTは[RFC7519]のセクション11.2で説明されるように、署名してから暗号化されなければならない。その結果は、[RFC7519]で定義される Nested JWTである。¶

クライアントは、リクエストオブジェクトの署名および暗号化に使用するアルゴリズムを決定する。選択されたアルゴリズムは、クライアントと認可サーバーの両方でサポートされている必要がある。クライアントは、自身がサポートするアルゴリズムを動的クライアント登録メタデータ[RFC7591]で、具体的にはメタデータ値 request_object_signing_alg、 request_object_encryption_alg、および request_object_encryption_encによって認可サーバーに通知できる。同様に、認可サーバーは、自身がサポートするアルゴリズムを認可サーバーメタデータ[RFC8414]で、具体的にはメタデータ値 request_object_signing_alg_values_supported、 request_object_encryption_alg_values_supported、および request_object_encryption_enc_values_supportedによってクライアントに通知できる。¶

リクエストオブジェクトは、セクション5.1で説明されるように値として送信してもよく、セクション5.2で説明されるように参照として送信してもよい。 requestおよび request_uriパラメータはリクエストオブジェクトに含めてはならない。¶

リクエストオブジェクト（セクション2.1）のメディアタイプ[RFC2046]は application/oauth-authz-req+jwtである。一部の既存のデプロイメントでは、代替として application/jwt型を使用している場合があることに注意すること。¶

次は、base64url [RFC7515]エンコードおよび署名前のリクエストオブジェクト内のClaimsの例である。これには拡張パラメータ nonceおよびmax_ageが含まれることに注意すること。¶

  {
   "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
  }

RS256アルゴリズム[RFC7518]で署名すると、次のリクエストオブジェクト値になる（値内の改行は表示目的のみ）:¶

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

次のRSA公開鍵は、JSON Web Key (JWK)形式で表されており、この例および後続のリクエストオブジェクト例におけるリクエストオブジェクト署名を検証するために使用できる（値内の改行は表示目的のみ）:¶

  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
        pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
        ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
        w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
        lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
        UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
   "e":"AQAB"
  }

5. 認可リクエスト

クライアントは、application/x-www-form-urlencoded 形式を用いて、認可エンドポイントURIのクエリコンポーネントに次のパラメータを追加することにより、認可リクエストURIを構築する:¶

request: request_uriが指定されていない限りREQUIRED。リクエストオブジェクト（セクション2.1）であり、 [RFC6749]のセクション4（OAuth 2.0）で述べられる認可リクエストパラメータを保持する。このパラメータが認可リクエストに存在する場合、 request_uriは存在してはならない。¶
request_uri: requestが指定されていない限りREQUIRED。 RFC 3986 [RFC3986]で定義される絶対URIであり、 [RFC6749]のセクション4（OAuth 2.0）で述べられる認可リクエストパラメータを参照するリクエストオブジェクトURI（セクション 2.2）である。このパラメータが認可リクエストに存在する場合、 requestは存在してはならない。¶
client_id: REQUIRED。OAuth 2.0 [RFC6749] client_id。その値は、 requestまたはrequest_uriのリクエストオブジェクト（セクション2.1）の client_idと一致しなければならない。¶

クライアントは、HTTPリダイレクトレスポンスまたはユーザーエージェントを介して利用可能なその他の手段を用いて、リソース所有者を構築されたURIに誘導する。¶

例えば、クライアントは、エンドユーザーのユーザーエージェントに次のHTTPSリクエストを行わせる:¶

GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com

requestパラメータの値は、簡潔にするため省略されている。¶

認可リクエストオブジェクトは、次のいずれかでなければならない:¶

(a): JWS署名付き¶
(b): JWS署名付きかつJWE暗号化済み¶

クライアントは、後方互換性などのために、リクエストオブジェクトに含まれるパラメータをクエリパラメータにも重複して送信してもよい。ただし、この仕様をサポートする認可サーバーは、リクエストオブジェクトに含まれるパラメータのみを使用しなければならない。¶

5.1. リクエストオブジェクトを値として渡す

クライアントは、認可リクエストを requestパラメータ値として認可エンドポイントにリクエストオブジェクトとして送信する。¶

次は、request パラメータを使用する認可リクエストの例である（値内の改行は表示目的のみ）:¶

  https://server.example.com/authorize?client_id=s6BhdRkqt3&
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g

5.2. リクエストオブジェクトを参照として渡す

request_uri認可リクエストパラメータにより、 OAuth認可リクエストを値ではなく参照として渡せる。このパラメータは、リクエストオブジェクト値が値として渡されるのではなく、指定されたURIで識別されるリソースから取得される点を除き、 requestパラメータと同じように使用される。¶

リクエストURI全体は512 ASCII文字を超えるべきではない。この制限には2つの理由がある:¶

本稿執筆時点で市場にある多くの携帯電話は、依然として大きなペイロードを受け付けない。制限は通常512または1024 ASCII文字である。¶
2Gモバイル接続のような低速接続では、大きなURLは応答を遅くするため、ユーザー体験の観点からそのような使用は推奨されない。¶

request_uriによって参照されるリソースの内容は、そのURIが認可サーバーからクライアントに提供されたものでない限り、リクエストオブジェクトでなければならず、かつ認可サーバーから到達可能でなければならない。前者の場合、request_uriは [RFC7230]のセクション2.7.2で規定される https URIでなければならない。後者の場合、それは [RFC8141]で規定されるURNでなければならない。¶

次は、 request_uriによって参照できるリクエストオブジェクトリソースの内容の例である（値内の改行は表示目的のみ）:¶

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

5.2.1. リクエストオブジェクトを参照するURI

クライアントは、認可サーバーがアクセスできるURIに、リクエストオブジェクトリソースをローカルまたはリモートに保存する。そのような機能は、認可サーバーまたは信頼された第三者によって提供されてもよい。例えば、認可サーバーはクライアントがリクエストオブジェクトをPOSTし、リクエストURIを取得するURLを提供してもよい。このURIがリクエストオブジェクトURI、すなわちrequest_uriである。¶

リクエストオブジェクトに、認可サーバーにだけ開示されるべき値が含まれる可能性がある。そのため、request_uriは公開取得可能であっても推測されないように、その有効期間に応じた適切なエントロピーを持たなければならない。指針については、 [RFC6819]のセクション5.1.4.2.2および「Capability URLのための優良実践」[CapURLs]を参照すること。アクセス制御手段が講じられていない限り、 request_uriは妥当なタイムアウト後に削除することがRECOMMENDEDである。¶

次は、リクエストオブジェクトURI値の例である（値内の改行は表示目的のみ）。この例では、信頼された第三者サービスがリクエストオブジェクトをホストしている。¶

  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

5.2.2. "request_uri"リクエストパラメータを用いるリクエスト

クライアントは、認可リクエストを認可エンドポイントに送信する。¶

次は、 request_uriパラメータを使用する認可リクエストの例である（値内の改行は表示目的のみ）:¶

  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

5.2.3. 認可サーバーがリクエストオブジェクトを取得する

リクエストを受信すると、認可サーバーは、そのサーバーが別の仕組みを通じて安全に取得し、解析して認可リクエストパラメータを再作成できるような方法でリクエストオブジェクトが保存されていない限り、参照されたリクエストオブジェクトを取得するために、 request_uriへHTTP GETリクエストを送信しなければならない。¶

次は、この取得処理の例である。この例では、信頼された第三者サービスがリクエストオブジェクトをホストしている。¶

GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org

次は、取得レスポンスの例である:¶

  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

6. JWTベースのリクエストの検証

6.1. JWE暗号化リクエストオブジェクト

リクエストオブジェクトが暗号化されている場合、認可サーバーはJSON Web Encryption [RFC7516] 仕様に従ってJWTを復号しなければならない。¶

その結果は、署名付きリクエストオブジェクトである。¶

復号に失敗した場合、認可サーバーは認可リクエストへの応答として、invalid_request_objectエラーをクライアントに返さなければならない。¶

6.2. JWS署名付きリクエストオブジェクト

認可サーバーは、JWS署名付き[RFC7515] リクエストオブジェクトの署名を検証しなければならない。 kidヘッダーパラメータが存在する場合、識別された鍵は使用される鍵でなければならず、かつクライアントに関連付けられた鍵でなければならない。署名は、クライアントに関連付けられた鍵と algヘッダーパラメータで指定されたアルゴリズムを使用して検証されなければならない。アルゴリズム検証は、 [RFC8725]のセクション3.1および3.2で規定されるように実行されなければならない。¶

鍵がクライアントに関連付けられていない場合、または署名検証に失敗した場合、認可サーバーは認可リクエストへの応答として invalid_request_objectエラーをクライアントに返さなければならない。¶

6.3. リクエストパラメータの組み立ておよび検証

認可サーバーは、リクエストオブジェクト値から認可リクエストパラメータの集合を抽出しなければならない。認可サーバーは、同じパラメータがクエリパラメータで提供されている場合でも、リクエストオブジェクト内のパラメータのみを使用しなければならない。 client_idリクエストパラメータ内のクライアントID値とリクエストオブジェクトのclient_id claim内のクライアントID値は同一でなければならない。その後、認可サーバーはOAuth 2.0 [RFC6749]で規定されるようにリクエストを検証する。¶

クライアントIDの確認またはリクエスト検証に失敗した場合、認可サーバーは、[RFC6749]のセクション 5.2（OAuth 2.0）で規定されるように、認可リクエストへの応答としてクライアントにエラーを返さなければならない。¶

9. IANAに関する考慮事項

9.1. OAuthパラメータの登録

リクエストオブジェクトはJWTであるため、コアJWT claimsは、 JWTが規定する目的以外でリクエストオブジェクト内に使用できない。したがって、将来のOAuth拡張がそれらを異なる意味で使用することを避けるため、OAuth認可リクエストパラメータとして登録されている。¶

この仕様は、[RFC6749]により確立された"OAuth Parameters"レジストリ [IANA.OAuth.Parameters]に、次の値を追加する。¶

名前:: iss¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.1。¶

名前:: sub¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.2。¶

名前:: aud¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.3。¶

名前:: exp¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.4。¶

名前:: nbf¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.5。¶

名前:: iat¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.6。¶

名前:: jti¶
パラメータ使用場所:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および [RFC7519]のセクション 4.1.7。¶

9.2. OAuth認可サーバーメタデータレジストリ

この仕様は、[RFC8414]により確立された"OAuth Authorization Server Metadata"レジストリ [IANA.OAuth.Parameters]に、次の値を追加する。¶

メタデータ名:: require_signed_request_object¶
メタデータ説明:: 認可リクエストをリクエストオブジェクトとして保護し、 requestまたはrequest_uri parameterのいずれかを通じて提供する必要がある場所を示す。¶
変更管理者:: IETF¶
仕様文書:: 本文書のセクション10.5。¶

9.3. OAuth動的クライアント登録メタデータレジストリ

この仕様は、[RFC7591]により確立された"OAuth Dynamic Client Registration Metadata"レジストリ [IANA.OAuth.Parameters]に、次の値を追加する。¶

メタデータ名:: require_signed_request_object¶
メタデータ説明:: 認可リクエストをリクエストオブジェクトとして保護し、 requestまたはrequest_uri parameterのいずれかを通じて提供する必要がある場所を示す。¶
変更管理者:: IETF¶
仕様文書:: 本文書のセクション10.5。¶

9.4. メディアタイプ登録

9.4.1. レジストリの内容

このセクションは、 application/oauth-authz-req+jwt メディアタイプ[RFC2046]を、 [RFC6838]で説明される方法により、 "Media Types"レジストリ [IANA.MediaTypes]に登録する。これは、内容がリクエストオブジェクトclaimsを含むJWTであることを示すために使用できる。¶

タイプ名:

application¶

サブタイプ名:

oauth-authz-req+jwt¶

必須パラメータ:

N/A¶

任意パラメータ:

N/A¶

エンコーディングに関する考慮事項:

binary; リクエストオブジェクトはJWTである。 JWT値は、ピリオド（.）文字で区切られた一連のbase64urlエンコード値（その一部は空文字列の場合がある）としてエンコードされる。¶

セキュリティに関する考慮事項:

RFC 9101のセクション10を参照¶

相互運用性に関する考慮事項:

N/A¶

公開仕様:

RFC 9101のセクション4 ¶

このメディアタイプを使用するアプリケーション:

OAuth 2.0認可リクエストを行うためにリクエストオブジェクトを使用するアプリケーション¶

フラグメント識別子に関する考慮事項:

N/A¶

追加情報:

このタイプの非推奨エイリアス名:: N/A¶
マジックナンバー:: N/A¶
ファイル拡張子:: N/A¶
Macintoshファイルタイプコード:: N/A¶

詳細情報の連絡先氏名およびメールアドレス:

Nat Sakimura <nat@nat.consulting>¶

想定される用途:

COMMON¶

使用上の制限:

なし¶

著者:

Nat Sakimura <nat@nat.consulting>¶

変更管理者:

IETF¶

暫定登録か?

いいえ¶

10. セキュリティに関する考慮事項

OAuth 2.0で論じられているセキュリティに関するすべての考慮事項 [RFC6819]に加え、 [RFC7515]、[RFC7516]、 [RFC7518]、および[RFC8725]のセキュリティに関する考慮事項を考慮する必要がある。また、[BASIN]など、OAuthのようなプロトコルのセキュリティ特性に関して有用な洞察を提供する学術論文もいくつかある。¶

上記を考慮し、本文書は次のセキュリティに関する考慮事項を考慮に入れることを助言する。¶

10.1. アルゴリズムの選択

認可リクエストオブジェクトを requestパラメータを通じて送信する場合、その時点で適切と考えられるアルゴリズムを用いて、 JWS [RFC7515]で署名されているか、またはJWS [RFC7515]および JWE [RFC7516]をそれぞれ使用して署名された後に暗号化されていなければならない。¶

10.2. リクエスト送信元認証

認可リクエストの送信元は常に検証されなければならない。それを行う方法はいくつかある:¶

(a): リクエストオブジェクトのJWS署名を検証する。¶
(b): JWEが対称暗号を使用している場合、 JWE暗号化の対称鍵が正しいものであることを検証する。ただし、公開鍵暗号が使用される場合、どの当事者でも公開鍵に暗号化できるため、暗号化によって送信元認証は有効にならないことに注意する。¶
(c): リクエストオブジェクトURIのTLSサーバーIDを検証する。この場合、認可サーバーはクライアントがリクエストオブジェクトURIを使用し、かつTLS証明書で対象となるのがそのクライアントのみであることを帯域外で知っていなければならない。一般に、これは信頼できる方法ではない。¶
(d): 認可サーバーが、リクエストオブジェクトと引き換えにリクエストオブジェクトURIを返すサービスを実装する場合、認可サーバーはリクエストオブジェクトを受け付けるためにクライアント認証を実行し、提供するリクエストオブジェクトURIにクライアント識別子を結び付けなければならない。それは(a)に従って署名を検証しなければならない。リクエストオブジェクトURIは再生され得るため、リクエストオブジェクトURIの有効期間は短く、できれば一回限りの使用でなければならない。リクエストオブジェクトURIのエントロピーは十分に大きくなければならない。有効性の適切な短さとリクエストオブジェクトURIのエントロピーは、保護されるリソースの価値に基づくリスク計算に依存する。有効期間の一般的な指針は 1分未満であり、リクエストオブジェクトURIには、この仕様の執筆時点で128ビット以上の暗号学的ランダム値を含めるべきである。¶
(e): 信頼された第三者サービスがリクエストオブジェクトと引き換えにリクエストオブジェクトURIを返す場合、それは(a)に従って署名を検証しなければならない。さらに、認可サーバーはその第三者サービスに信頼されていなければならず、クライアントもその第三者サービスに信頼されていることを帯域外で知っていなければならない。¶

10.3. 明示的なエンドポイント

この仕様はそれらを要求しないが、 [BASIN]などの研究は、起動者の意図が曖昧でないように、意図された相互作用エンドポイントとシーケンス内のメッセージ位置を、改ざんが検出可能な方法で明示的に示すことが優良実践であると指摘している。この仕様は、[RFC6749]、[RFC6750]、および[RFC8414]で定義される次のエンドポイントに対して、この実践を使用することをRECOMMENDEDする:¶

(a): 保護されたリソース（protected_resources）¶
(b): 認可エンドポイント（authorization_endpoint）¶
(c): リダイレクトURI（redirect_uri）¶
(d): トークンエンドポイント（token_endpoint）¶

さらに、動的ディスカバリが使用される場合、この実践はディスカバリ関連のエンドポイントにも適用される。¶

[RFC6749]では、リダイレクトURIは認可リクエストに含まれるが、その他は含まれない。その結果、同じことが認可リクエストオブジェクトにも適用される。¶

10.4. request_uriに関連するリスク

request_uriの導入は、いくつかの攻撃の可能性を導入する。 URIに関連するリスクの詳細については、 [RFC3986]のセクション7のセキュリティに関する考慮事項を参照すること。¶

10.4.1. 認可サーバーに対するDDoS攻撃

悪意のあるクライアント群は、 request_uriに、極めて大きなコンテンツを返すURI、または応答が極めて遅いURIを指定することで、認可サーバーにDoS攻撃を仕掛けることができる。このような攻撃下では、サーバーはリソースを使い果たし、障害を起こし始める可能性がある。¶

同様に、悪意のあるクライアントは、再帰的なルックアップを引き起こすために、 request_uriを使用する認可リクエストURI自体を指す request_uri値を指定できる。¶

このような攻撃が成功するのを防ぐため、サーバーは a) request_uriパラメータの値が予期しない場所を指していないことを確認し、 b) レスポンスのメディアタイプが application/oauth-authz-req+jwtであることを確認し、 c) request_uriの内容を取得するためのタイムアウトを実装し、 d) request_uriに対して再帰的なGETを行わないようにするべきである。¶

10.4.2. リクエストURIの書き換え

request_uriの値は署名されないため、 man-in-the-browser攻撃者によって改ざんされ得る。このため、いくつかの攻撃の可能性が生じる。例えば、 a) 攻撃者は書き換えられたURIが指す別のファイルを作成し、追加のscopeを要求できるようにする可能性があり、または b) 攻撃者はrequest_uriの値を被害サイトのものに設定して、被害サイトにDoS攻撃を仕掛ける可能性がある。¶

10.5. ダウングレード攻撃

クライアントとサーバーが使用するプロトコルが OAuth JWT-Secured Authorization Request (JAR)を使用するように固定されていない限り、攻撃者がRFC 6749リクエストを使用して、この仕様によって提供されるすべての保護を回避することが可能である。¶

この種の攻撃を防ぐため、この仕様は、クライアントメタデータおよびサーバーメタデータの新しい値を定義する。どちらもrequire_signed_request_objectという名前で、値はいずれもブール値である。¶

クライアントメタデータとしてのその値がtrueである場合、サーバーは、この仕様に準拠しないクライアントからの認可リクエストを拒否しなければならない。また、このサーバーメタデータ値がtrueであるときにリクエストオブジェクトがnoneのalg値を使用する場合も、リクエストを拒否しなければならない。省略された場合、デフォルト値はfalseである。¶

サーバーメタデータとしてのその値がtrueである場合、サーバーは、この仕様に準拠しない任意のクライアントからの認可リクエストを拒否しなければならない。また、リクエストオブジェクトがnoneのalg値を使用する場合も、リクエストを拒否しなければならない。省略された場合、デフォルト値はfalseである。¶

require_signed_request_objectメタデータ値が存在しない場合でも、クライアントとサーバーが相互にサポートする署名アルゴリズムがあれば、クライアントは署名付きリクエストオブジェクトを使用してもよいことに注意すること。署名アルゴリズムメタデータの使用については、セクション4で説明されている。¶

10.6. TLSセキュリティに関する考慮事項

現在のセキュリティに関する考慮事項は、「Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)」 [RFC7525]に記載されている。これは OAuth 2.0 [RFC6749]における TLSバージョンの推奨事項を置き換える。¶

10.7. パラメータの不一致

OAuthパラメータ値が、通常のOAuthパラメータとして、またリクエストオブジェクトclaimsとして、2つの異なる場所で送信されることを考えると、実装は、不一致のパラメータ値を利用して意図しない結果を得ようとする攻撃から保護しなければならない。これが、2つのクライアントID値が一致しなければならない理由であり、リクエストオブジェクトからのパラメータ値のみを使用する理由であり、 requestもrequest_uriもリクエストオブジェクト内に現れてはならない理由である。¶

10.8. Cross-JWT混同

[RFC8725]のセクション2.8で説明されるように、攻撃者は、ある目的のために発行されたJWTを、それが意図されていないコンテキストで使用しようと試みる可能性がある。これらの攻撃に対して説明されている緩和策は、リクエストオブジェクトにも適用できる。¶

攻撃者がリクエストオブジェクトを別用途に転用しようとする一つの方法は、 [RFC7523]のセクション2.2で説明されるように、それをクライアント認証JWTとして使用しようとすることである。これを防ぐ簡単な方法は、リクエストオブジェクト内のsub値としてクライアントIDを決して使用しないことである。¶

Cross-JWT混同を防ぐもう一つの方法は、 [RFC8725]のセクション3.11で説明されるように、明示的な型付けを使用することである。リクエストオブジェクトは、値 oauth-authz-req+jwt （セクション9.4.1で登録されている）を持つ typヘッダーパラメータを含めることで明示的に型付けできる。ただし、既存の認可サーバーで明示的に型付けされたリクエストオブジェクトを要求すると、既存のクライアントは、特にOpenID Connect [OpenID.Core]で、すでに型付けされていないリクエストオブジェクトを一般的に使用しているため、ほとんどの既存のデプロイメントを破壊することに注意すること。しかし、既存のデプロイメントとの互換性を考慮しない新しいOAuth デプロイメントプロファイルでは、明示的な型付けを要求することは良い考えである。¶

最後に、Cross-JWT混同を防ぐさらに別の方法は、リクエストオブジェクトの署名に使用される鍵が、他の目的に使用される鍵と識別可能な形で区別される鍵管理体制を使用することである。そうすれば、敵対者がリクエストオブジェクトを別のコンテキストで転用しようとした場合、鍵の不一致が発生し、攻撃を阻止できる。¶

11. プライバシーに関する考慮事項

クライアントが、個人データを含む保護されたリソースへのアクセスを許可される場合、クライアントと認可サーバーの両方はプライバシー原則を遵守する必要がある。「Privacy Considerations for Internet Protocols」 [RFC6973]は、プロトコル設計および実装の改善について優れた指針を提供している。そこに列挙されている規定に従うべきである。¶

ほとんどの規定は、「The OAuth 2.0 Authorization Framework」[RFC6749]および「The OAuth 2.0 Authorization Framework: Bearer Token Usage」 [RFC6750]に適用されるものであり、この仕様に固有のものではない。以下では、この仕様に固有の規定のみを記す。¶

11.1. 収集制限

クライアントが、個人データを含む保護されたリソースへのアクセスを許可される場合、クライアントは、適用法の範囲内で、かつ指定された目的のために厳密に必要なものに個人データの収集を制限するべきである。¶

要求された個人データが厳密に必要かどうかをユーザーが判断することはしばしば難しい。信頼された第三者サービスは、クライアントリクエストを検査し、それをクライアントによる提案された処理と比較し、リクエストを認証することによってユーザーを支援できる。認証後、クライアントは認可リクエストを行う際に、信頼された第三者サービスに認可リクエストを送信してリクエストオブジェクトURIを取得できる。このプロセスには2つのステップがある:¶

(1): （認証プロセス）信頼された第三者サービスはクライアントの業務プロセスを検査し、どのclaimsが必要かを判断する。これが認証プロセスである。クライアントが認証されると、 request_uriを取得するためにリクエストオブジェクトを信頼された第三者サービスへプッシュする際に認証するためのクライアント資格情報が発行される。¶
(2): （変換プロセス）クライアントは取得したクライアント資格情報を使用して、リクエストオブジェクトを信頼された第三者サービスへプッシュし、request_uriを取得する。信頼された第三者サービスはまた、前のステップに従い、リクエストオブジェクトがクライアントに許可されているclaimsと一貫していることを検証する。¶

認可リクエストでそのようなリクエストオブジェクトURIを受信すると、認可サーバーはまず、リクエストオブジェクトURIのauthority部分が信頼された第三者サービスにとって正当なものであることを検証する。次に、認可サーバーはリクエストオブジェクトURIへHTTP GETリクエストを発行する。接続時、認可サーバーは、TLS証明書で表されるサーバーIDがリクエストオブジェクトURIにとって正当であることを検証しなければならない。その後、認可サーバーはクライアントを表すclient_idを含むリクエストオブジェクトを取得できる。¶

同意画面はクライアントを示さなければならず、収集制限原則の遵守について、そのリクエストが信頼された第三者サービスによって審査済みであることを示すべきである。¶

11.2. 開示制限

11.2.1. リクエストの開示

この仕様は拡張パラメータを許可する。これらは潜在的に機微な情報を含む場合がある。 URIクエリパラメータはさまざまな手段で漏えいする可能性があり、特にreferrerおよびブラウザ履歴を通じて漏えいし得るため、認可リクエストが潜在的に機微なパラメータを含む場合、クライアントはJWE [RFC7516]を使用してリクエストオブジェクトを暗号化するべきである。¶

リクエストオブジェクトURI方式が使用されている場合で、リクエストオブジェクトが個人を識別可能な情報または機微な情報を含むとき、リクエストオブジェクト自体が JWE [RFC7516]を使用して暗号化されていない限り、request_uriは一度だけ使用され、短い有効期間を持つべきであり、かつ適用されるセキュリティポリシーに対して十分なエントロピーを持たなければならない。リクエストオブジェクトURIの有効性の適切な短さとエントロピーは、保護されるリソースの価値に基づくリスク計算に依存する。有効期間の一般的な指針は 1分未満であり、リクエストオブジェクトURIには、この仕様の執筆時点で128ビット以上の暗号学的ランダム値を含めるべきである。¶

[RFC2119]: Bradner, S., "RFCで要件レベルを示すために用いるキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629]: Yergeau, F., "UTF-8、ISO 10646の変換形式", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月, <https://www.rfc-editor.org/info/rfc3986>.
[RFC6125]: Saint-Andre, P. and J. Hodges, "Transport Layer Security (TLS)の文脈におけるX.509 (PKIX)証明書を用いたインターネット公開鍵基盤内のドメインベースアプリケーションサービスIDの表現および検証", RFC 6125, DOI 10.17487/RFC6125, 2011年3月, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6749]: Hardt, D., Ed., "OAuth 2.0認可フレームワーク", RFC 6749, DOI 10.17487/RFC6749, 2012年10月, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750]: Jones, M. and D. Hardt, "OAuth 2.0認可フレームワーク: Bearer Tokenの使用法", RFC 6750, DOI 10.17487/RFC6750, 2012年10月, <https://www.rfc-editor.org/info/rfc6750>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): メッセージ構文およびルーティング", RFC 7230, DOI 10.17487/RFC7230, 2014年6月, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7515]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015年5月, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516]: Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, 2015年5月, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7518]: Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, 2015年5月, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, 2015年5月, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525]: Sheffer, Y., Holz, R., and P. Saint-Andre, "Transport Layer Security (TLS) およびDatagram Transport Layer Security (DTLS)の安全な使用に関する推奨事項", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 2015年5月, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8141]: Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, 2017年4月, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8174]: Leiba, B., "RFC 2119キーワードにおける大文字と小文字の曖昧性", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]: Bray, T., Ed., "JavaScript Object Notation (JSON)データ交換形式", STD 90, RFC 8259, DOI 10.17487/RFC8259, 2017年12月, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8414]: Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0認可サーバーメタデータ", RFC 8414, DOI 10.17487/RFC8414, 2018年6月, <https://www.rfc-editor.org/info/rfc8414>.

12.2. 参考情報としての参考文献

[BASIN]: Basin, D., Cremers, C., and S. Meier, "エンティティ認証のためのISO/IEC 9798 標準の証明可能な修復", Journal of Computer Security - Security and Trust Principles, Volume 21, Issue 6, pp. 817-846, 2013年11月, <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-iso9798.pdf>.
[CapURLs]: Tennison, J., Ed., "Capability URLのための優良実践", W3C First Public Working Draft, 2014年2月18日, <https://www.w3.org/TR/capability-urls/>.
[IANA.JWT.Claims]: IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.
[IANA.MediaTypes]: IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[IANA.OAuth.Parameters]: IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[OpenID.Core]: Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", OpenID Foundation Standards, 2014年11月8日, <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2046]: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: メディアタイプ", RFC 2046, DOI 10.17487/RFC2046, 1996年11月, <https://www.rfc-editor.org/info/rfc2046>.
[RFC6819]: Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0脅威モデルおよびセキュリティに関する考慮事項", RFC 6819, DOI 10.17487/RFC6819, 2013年1月, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6838]: Freed, N., Klensin, J., and T. Hansen, "メディアタイプ仕様および登録手続き", BCP 13, RFC 6838, DOI 10.17487/RFC6838, 2013年1月, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6973]: Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "インターネットプロトコルにおけるプライバシーに関する考慮事項", RFC 6973, DOI 10.17487/RFC6973, 2013年7月, <https://www.rfc-editor.org/info/rfc6973>.
[RFC7523]: Jones, M., Campbell, B., and C. Mortimore, "OAuth 2.0クライアント認証および認可付与のためのJSON Web Token (JWT)プロファイル", RFC 7523, DOI 10.17487/RFC7523, 2015年5月, <https://www.rfc-editor.org/info/rfc7523>.
[RFC7591]: Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0動的クライアント登録プロトコル", RFC 7591, DOI 10.17487/RFC7591, 2015年7月, <https://www.rfc-editor.org/info/rfc7591>.
[RFC8725]: Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Tokenのベストカレントプラクティス", BCP 225, RFC 8725, DOI 10.17487/RFC8725, 2020年2月, <https://www.rfc-editor.org/info/rfc8725>.