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): 関連する署名および暗号化方式とともに、 Proposed Standard として開発されていること [RFC7515] [RFC7516]¶
(5): XML Signature および Encryption と比較して JWS と JWE が比較的扱いやすいこと。¶

パラメーター request および request_uri は、 OAuth 2.0 [RFC6749] フロー用の追加の認可リクエストパラメーターとして導入されます。 request パラメーターは、 JWT Claims Set に JSON エンコードされた OAuth 2.0 認可リクエストパラメーターを保持する JSON Web Token (JWT) [RFC7519] です。 RFC 7519 とは異なり、Claims Set の要素はエンコードされた OAuth リクエストパラメーター [IANA.OAuth.Parameters] であり、 IANA が管理する JSON Web Token Claim [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 認可リクエストの認可リクエストパラメーターを提供するために使用されます。これは、OAuth 2.0 [RFC6749] の認可リクエストを処理するために使用されるすべてのパラメーター（拡張パラメーターを含む）を、この文書で定義される request および request_uri パラメーターを除いて、MUST 含まなければなりません。パラメーターはオブジェクトの JWT Claim として表現されます。パラメーター名および文字列値は JSON 文字列として MUST 含めなければなりません。リクエストオブジェクトはドメインをまたいで処理され、閉じたエコシステムの外部で扱われる可能性があるため、第8.1節 of [RFC8259] に従い、これらの JSON 文字列は UTF-8 [RFC3629] を使用して MUST エンコードしなければなりません。数値は JSON 数値として MUST 含めなければなりません。リクエストオブジェクトは任意の拡張パラメーターを MAY 含めることができます。この JSON [RFC8259] オブジェクトは、 JWT [RFC7519] で定義されている JWT Claims Set を構成します。 JWT Claims Set はその後、署名されるか、署名されて暗号化されます。¶

署名には、JSON Web Signature (JWS) [RFC7515] が使用されます。その結果、JWS 署名された JWT [RFC7519] になります。署名されている場合、認可リクエストオブジェクトは、Claim iss（発行者）および aud（対象者）を、 JWT [RFC7519] 仕様で定義されたものと同じ意味を持つメンバーとして SHOULD 含むべきです。aud の値は、 RFC 8414 [RFC8414] で定義される認可サーバー (AS) の issuer の値であるべきです。¶

暗号化には、JWE [RFC7516] が使用されます。署名と暗号化の両方を適用する場合、 JWT は、第11.2節 of [RFC7519] に記載されているとおり、最初に署名し、その後暗号化 MUST しなければなりません。その結果は、 [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節で説明されているように値で MAY 送信でき、または第5.2節で説明されているように参照で送信できます。 request および request_uri パラメーターはリクエストオブジェクトに MUST NOT 含めてはなりません。¶

リクエストオブジェクト (第2.1節) のメディアタイプ [RFC2046] は application/oauth-authz-req+jwt です。既存の一部のデプロイメントでは、代わりに application/jwt タイプを使用している場合があることに注意してください。¶

次は、base64url [RFC7515] エンコードおよび署名前のリクエストオブジェクト内の Claim の例です。拡張パラメーター 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

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

  {
   "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 です。第4節 of [RFC6749] (OAuth 2.0) に記載された認可リクエストパラメーターを保持するリクエストオブジェクト (第2.1節)。このパラメーターが認可リクエストに存在する場合、 request_uri は存在しては MUST NOT なりません。¶
request_uri: request が指定されていない限り REQUIRED です。RFC 3986 [RFC3986] で定義されている絶対 URI であり、第4節 of [RFC6749] (OAuth 2.0) に記載された認可リクエストパラメーターを参照するリクエストオブジェクト URI (第 2.2節) です。このパラメーターが認可リクエストに存在する場合、 request は存在しては MUST NOT なりません。¶
client_id: REQUIRED。OAuth 2.0 [RFC6749] の client_id です。この値は、 request または request_uri のリクエストオブジェクト (第2.1節) の client_id と一致しなければ MUST なりません。¶

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

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

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

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

認可リクエストオブジェクトは次のいずれかでなければ MUST なりません:¶

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

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

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 認可リクエストを値ではなく参照によって渡すことができます。このパラメーターは request パラメーターと同様に使用されますが、リクエストオブジェクト値は値として渡されるのではなく、指定された URI で識別されるリソースから取得されます。¶

リクエスト URI 全体は 512 ASCII 文字を超えるべきでは SHOULD NOT ありません。この制限には2つの理由があります:¶

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

request_uri が参照するリソースの内容は、 URI が認可サーバーからクライアントに提供された場合を除き、リクエストオブジェクトで MUST なければならず、認可サーバーから到達可能で MUST なければなりません。前者の場合、request_uri は、第2.7.2節 of [RFC7230] で規定されている https URI で MUST なければなりません。後者の場合は、 [RFC8141] で規定されている URN で MUST なければなりません。¶

次は、 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 は、公開で取得可能な場合に URI を推測できないよう、その有効期間に対して適切なエントロピーを MUST 持たなければなりません。指針については、第5.1.4.2.2節 of [RFC6819] および "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 リクエストを MUST 送信しなければなりません。¶

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

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 を復号しなければ MUST なりません。¶

結果は署名されたリクエストオブジェクトです。¶

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

6.2. JWS で署名されたリクエストオブジェクト

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

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

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

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

クライアント ID の確認またはリクエストの検証に失敗した場合、認可サーバーは、第 5.2節 of [RFC6749] (OAuth 2.0) で規定されているとおり、認可リクエストへの応答としてクライアントにエラーを返さなければ MUST なりません。¶

9. IANA に関する考慮事項

9.1. OAuth パラメーターの登録

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

本仕様は、[RFC6749] によって設立された "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] に次の値を追加します。¶

名前:: iss¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.1節 of [RFC7519]。¶

名前:: sub¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.2節 of [RFC7519]。¶

名前:: aud¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.3節 of [RFC7519]。¶

名前:: exp¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.4節 of [RFC7519]。¶

名前:: nbf¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.5節 of [RFC7519]。¶

名前:: iat¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.6節 of [RFC7519]。¶

名前:: jti¶
パラメーター使用位置:: 認可リクエスト¶
変更管理者:: IETF¶
仕様文書:: 本文書および第 4.1.7節 of [RFC7519]。¶

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] に登録します。これは、内容がリクエストオブジェクト Claim を含む JWT であることを示すために使用できます。¶

タイプ名:

application¶

サブタイプ名:

oauth-authz-req+jwt¶

必須パラメーター:

該当なし¶

任意パラメーター:

該当なし¶

エンコードに関する考慮事項:

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

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

RFC 9101 の第10節を参照してください¶

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

該当なし¶

公開仕様:

RFC 9101 の第4節 ¶

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

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

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

該当なし¶

追加情報:

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

詳細情報の問い合わせ先となる人物およびメールアドレス:

Nat Sakimura <nat@nat.consulting>¶

想定用途:

一般用途¶

使用上の制限:

なし¶

著者:

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] で暗号化するかのいずれかでなければ MUST なりません。¶

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

認可リクエストの送信元は常に検証しなければ MUST なりません。これにはいくつかの方法があります:¶

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

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 に関連するリスクの詳細については、第7節 of [RFC3986] のセキュリティに関する考慮事項を参照してください。¶

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

悪意のある複数のクライアントは、 request_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 の参照先となる別のファイルを作成し、追加のスコープを要求できるようにすることや、 b) request_uri の値を被害者サイトに設定することで、被害者サイトに DoS 攻撃を仕掛けることが可能です。¶

10.5. ダウングレード攻撃

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

この種の攻撃を防ぐため、本仕様では require_signed_request_object という同じ名前を持つ新しいクライアントメタデータ値とサーバーメタデータ値を定義します。どちらの値もブール値です。¶

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

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

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

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

現在のセキュリティ上の考慮事項は、「Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) の安全な使用に関する推奨事項」 [RFC7525] に記載されています。これは、 OAuth 2.0 [RFC6749] の TLS バージョンに関する推奨事項に優先します。¶

10.7. パラメーターの不一致

OAuth パラメーター値が通常の OAuth パラメーターとリクエストオブジェクト Claim という2つの異なる場所で送信されるため、実装は、不一致のパラメーター値を利用して意図しない結果を得ようとする攻撃を防がなければなりません。これが、2つのクライアント ID 値が一致しなければ MUST ならない理由、リクエストオブジェクト内のパラメーター値だけを使用する理由、および request と request_uri のいずれもリクエストオブジェクト内に出現できない理由です。¶

10.8. JWT 間の混同

第2.8節 of [RFC8725] で説明されているように、攻撃者は、ある目的のために発行された JWT を、その JWT が意図されていないコンテキストで使用しようとする場合があります。これらの攻撃について説明されている緩和策は、リクエストオブジェクトにも適用できます。¶

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

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

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

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

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

ほとんどの規定は、「OAuth 2.0 認可フレームワーク」 [RFC6749] および「OAuth 2.0 認可フレームワーク：Bearer Token の使用」 [RFC6750] に適用されるものであり、本仕様に固有のものではありません。以下では、本仕様に固有の規定のみを記載します。¶

11.1. 収集の制限

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

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

(1): （認証プロセス）信頼できる第三者サービスはクライアントのビジネスプロセスを調査し、必要な Claim を決定します。これが認証プロセスです。クライアントが認証されると、信頼できる第三者サービスに対して認証し、リクエストオブジェクトをプッシュして request_uri を取得するためのクライアント資格情報が発行されます。¶
(2): （変換プロセス）クライアントは取得したクライアント資格情報を使用して、リクエストオブジェクトを信頼できる第三者サービスにプッシュし、 request_uri を取得します。信頼できる第三者サービスは、前のステップに従って、リクエストオブジェクトがクライアントに認められている Claim と一致していることも検証します。¶

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

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

11.2. 開示の制限

11.2.1. リクエストの開示

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

リクエストオブジェクト URI 方式を使用している場合、リクエストオブジェクトに個人を特定できる情報または機密情報が含まれている場合、リクエストオブジェクト自体が JWE [RFC7516] を使用して暗号化されていない限り、 request_uri は一度だけ使用し、有効期間を短くするべきであり、適用されるセキュリティポリシーに対して十分なエントロピーを持たなければ MUST なりません。適切な有効期間の短さおよびリクエストオブジェクト 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, 「統一資源識別子 (URI)：汎用構文」, 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, 「統一資源名 (URN)」, 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 - セキュリティと信頼の原則、第21巻、第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 最初の公開作業草案, 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, 「メディアタイプ」, <https://www.iana.org/assignments/media-types>.
[IANA.OAuth.Parameters]: IANA, 「OAuth パラメーター」, <https://www.iana.org/assignments/oauth-parameters>.
[OpenID.Core]: Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, 「正誤表セット1を取り込んだ OpenID Connect Core 1.0」, OpenID Foundation 標準, 2014年11月8日, <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2046]: Freed, N. and N. Borenstein, 「多目的インターネットメール拡張 (MIME) 第2部：メディアタイプ」, 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>.