OAuth 2.0 Token Introspection

Internet Engineering Task Force (IETF)                    J. Richer, Ed.
Request for Comments: 7662                                  2015年10月
Category: Standards Track
ISSN: 2070-1721

Abstract

本仕様は、保護対象リソースが OAuth 2.0 の Authorization Server に問い合わせ、OAuth 2.0 トークンがアクティブな状態かどうかを判定し、またそのトークンに関するメタ情報を取得するための方法を定義する。OAuth 2.0 の導入では、この方法を用いて Authorization Server から保護対象リソースへ、トークンの認可コンテキストに関する情報を伝達できる。

Status of This Memo

本文書は Internet Standards Track 文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を表す。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認されている。Internet Standards に関する詳細は RFC 5741 の第2節にある。

本文書の現状、正誤表（errata）、およびフィードバックの提供方法は以下から入手できる。\ http://www.rfc-editor.org/info/rfc7662

Copyright Notice

Copyright (c) 2015 IETF Trust および本文書の著者として特定された者。全権利留保。

本文書は、公開日時点で有効な、BCP 78 および IETF Trust の IETF 文書に関する法的規定（Legal Provisions Relating to IETF Documents）\ (http://trustee.ietf.org/license-info)\ の適用を受ける。これらの文書には、本仕様に関する権利および制約が記載されているため、注意深く確認すること。本文書から抽出された Code Components には、Trust Legal Provisions の第4.e節に記載された Simplified BSD License の本文を含めなければならず、また Simplified BSD License に記載のとおり無保証で提供される。

---

Table of Contents

• OAuth 2.0 Token Introspection
  • Abstract
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
    • 1.1. Notational Conventions
    • 1.2. Terminology
      • Token Introspection
      • Introspection Endpoint
  • 2. Introspection Endpoint
    • 2.1. Introspection Request
      • token
      • token_type_hint
    • 2.2. Introspection Response
      • active
      • scope
      • client_id
      • username
      • token_type
      • exp
      • iat
      • nbf
      • sub
      • aud
      • iss
      • jti
    • 2.3. Error Response
  • 3. IANA Considerations
    • 3.1. OAuth Token Introspection Response Registry
    • 3.1.1. Registration Template
      • Name
      • Description
      • Change controller
      • Specification document(s)
    • 3.1.2. Initial Registry Contents
  • 4. Security Considerations
  • 5. Privacy Considerations
  • 6. References
    • 6.1. Normative References
    • 6.2. Informative References
  • Appendix A. Use with Proof-of-Possession Tokens
  • Acknowledgements
  • Author's Address

---

1. Introduction

OAuth 2.0 [RFC6749] では、トークンの内容はクライアントにとって不透明である。つまり、（もし存在するなら）トークンそのものの内容や構造について、クライアントは何も知る必要がない。しかし、トークンには、現在の有効性、承認されたスコープ、そしてトークンが発行されたコンテキストに関する情報など、さまざまなメタデータが付随し得る。これらの情報は、提示されたトークンに基づいて保護対象リソースが認可判断を行ううえでしばしば不可欠である。

OAuth 2.0 は、Resource Server が Authorization Server から受け取ったトークンについてメタ情報を学習するためのプロトコルを定義していないため、このギャップを埋めるために複数の異なるアプローチが開発されてきた。たとえば、JWT [RFC7519] のような構造化トークン形式を用いる方法や、トークン情報を伝える独自のサービス間通信メカニズム（共有データベースや、保護されたエンタープライズ・サービス・バスなど）を用いる方法がある。

本仕様は、認可された保護対象リソースが Authorization Server に問い合わせ、OAuth 2.0 クライアントから提示された特定のトークンに対するメタデータ一式を判定できるプロトコルを定義する。メタデータには、トークンが現在アクティブかどうか（期限切れか、あるいはその他の理由で失効・取り消しされているか）、トークンが保持するアクセス権（通常は OAuth 2.0 のスコープで表現される）、そしてそのトークンが付与された認可コンテキスト（誰がトークンを承認したのか、どのクライアントに対して発行されたのかを含む）が含まれる。

トークン introspection により、その情報がトークン自身に含まれているかどうかに依存せずに保護対象リソースが情報を問い合わせられるため、構造化トークン値と併用しても、あるいは構造化トークン値とは独立にこの方法を利用してもよい。さらに、保護対象リソースは本仕様で述べる仕組みを用いて、特定の認可判断コンテキストでトークンを introspect し、適切に認可判断を行うために関連するメタデータを確認できる。

1.1. Notational Conventions

本文書中のキーワード 'MUST'、'MUST NOT'、'REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'NOT RECOMMENDED'、'MAY'、'OPTIONAL' は、[RFC2119] に記載のとおり解釈される。

特に断りがない限り、すべてのプロトコル・パラメータ名および値は大文字小文字を区別する。

1.2. Terminology

本節では、本仕様で使用する用語を定義する。本節は本仕様の規範的部分であり、実装に対する要求事項を課す。

本仕様は、OAuth 2.0 [RFC6749] で定義される "access token"、"authorization endpoint"、"authorization grant"、"authorization server"、"client"、"client identifier"、"protected resource"、"refresh token"、"resource owner"、"resource server"、および "token endpoint" という用語と、JSON Web Token (JWT) [RFC7519] で定義される "claim names" および "claim values" を用いる。

本仕様は、以下の用語を定義する:

Token Introspection

本文書で定義されるネットワーク・プロトコルを用いて、OAuth 2.0 トークンの現在の状態について問い合わせる行為。

Introspection Endpoint

トークン introspection の操作を実行するための OAuth 2.0 エンドポイント。

---

2. Introspection Endpoint

introspection endpoint は OAuth 2.0 のエンドポイントであり、OAuth 2.0 トークンを表すパラメータを受け取り、そのトークンを取り巻くメタ情報（当該トークンが現在アクティブかどうかを含む）を表す JSON [RFC7159] 文書を返す。

トークンがアクティブであるという定義は Authorization Server に依存するが、一般には、当該 Authorization Server により発行され、期限切れではなく、取り消しされておらず、introspection を呼び出した保護対象リソースで利用可能なトークンを指すことが多い。

introspection endpoint は、第4節に記載のとおりトランスポート層のセキュリティ機構により保護されなければならない（MUST）。保護対象リソースが introspection endpoint の位置をどのように発見するかは、本仕様の対象外である。

2.1. Introspection Request

保護対象リソースは、HTTP POST [RFC7231] リクエストを用いて introspection endpoint を呼び出し、[W3C.REC-html5-20141028] で定義される "application/x-www-form-urlencoded" データとしてパラメータを送信する。保護対象リソースは、トークンを表すパラメータと、Authorization Server の応答を助けるために保護対象リソースが把握している追加コンテキストを表す任意のパラメータを送信する。

token

REQUIRED。トークンの文字列値。Access Token の場合、OAuth 2.0 [RFC6749] の第5.1節で定義される token endpoint から返る "access_token" の値である。Refresh Token の場合、OAuth 2.0 [RFC6749] の第5.1節で定義される token endpoint から返る "refresh_token" の値である。その他のトークン種別は本仕様の対象外である。

token_type_hint

OPTIONAL。introspection に提出されたトークンの種別に関するヒント。保護対象リソースは、Authorization Server がトークンの探索を最適化できるよう、このパラメータを渡してもよい（MAY）。サーバが指定されたヒントでトークンを見つけられない場合、サポートするすべてのトークン種別にわたって探索を拡張しなければならない（MUST）。Authorization Server は、特にトークン種別を自動検出できる場合、このパラメータを無視してもよい（MAY）。このフィールドの値は、OAuth Token Revocation [RFC7009] で定義される "OAuth Token Type Hints" レジストリで定義される。

introspection endpoint は、クエリにさらなるコンテキストを与えるために、他の OPTIONAL パラメータを受け付けてもよい（MAY）。たとえば、Authorization Server は、トークンを提示しているクライアントが妥当かを判断するため、保護対象リソースにアクセスしているクライアントの IP アドレスを知りたい場合がある。これやその他のパラメータの定義は本仕様の対象外であり、サービス文書または本仕様の拡張として定義される。Authorization Server が追加情報なしにトークンの状態を判定できない場合、第2.2節に記載のとおりトークンがアクティブではないことを示す introspection response を返すべきである（SHOULD）。

トークンの走査攻撃を防ぐため、このエンドポイントは、OAuth 2.0 [RFC6749] で述べるクライアント認証など、あるいは OAuth 2.0 Bearer Token Usage [RFC6750] で述べる bearer token のような別の OAuth 2.0 Access Token など、何らかの認可を必ず要求しなければならない（MUST）。これらの認証資格情報の管理および検証方法は、本仕様の対象外である。

例として、以下は保護対象リソースがトークン introspection endpoint を呼び出し、OAuth 2.0 bearer token について問い合わせる様子を示す。保護対象リソースは、この呼び出しを認可するために別の OAuth 2.0 bearer token を用いている。

以下は非規範的なリクエスト例である:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

次の例では、保護対象リソースは client identifier と client secret を用いて introspection endpoint へ自身を認証する。保護対象リソースはまた、Access Token について問い合わせていることを示す token type hint を送信する。

以下は非規範的なリクエスト例である:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

token=mF_9.B5f-4.1JqM&token_type_hint=access_token

2.2. Introspection Response

サーバは、"application/json" 形式の JSON オブジェクト [RFC7159] を返し、そのトップレベルのメンバーとして以下を含める。

active

REQUIRED。提示されたトークンが現在アクティブかどうかを示す真偽値インジケータ。トークンの "active" 状態の詳細は Authorization Server の実装および保持しているトークン情報によって異なるが、一般に "active" プロパティが "true" で返る場合は、そのトークンが当該 Authorization Server により発行され、Resource Owner によって取り消しされておらず、かつ有効期間の時間窓内（例: 発行時刻より後、失効時刻より前）であることを示す。そのようなチェックの実装に関する情報は第4節を参照。

scope

OPTIONAL。このトークンに関連付けられたスコープの空白区切りリストを含む JSON 文字列。形式は OAuth 2.0 [RFC6749] の第3.3節に記載のとおり。

client_id

OPTIONAL。このトークンを要求した OAuth 2.0 client の client identifier。

username

OPTIONAL。このトークンを承認した Resource Owner の、人間が読める識別子。

token_type

OPTIONAL。OAuth 2.0 [RFC6749] の第5.1節で定義されるトークン種別。

exp

OPTIONAL。UTC の 1970年1月1日からの経過秒数で表される整数のタイムスタンプで、このトークンが失効する時刻を示す。JWT [RFC7519] で定義される。

iat

OPTIONAL。UTC の 1970年1月1日からの経過秒数で表される整数のタイムスタンプで、このトークンが元々発行された時刻を示す。JWT [RFC7519] で定義される。

nbf

OPTIONAL。UTC の 1970年1月1日からの経過秒数で表される整数のタイムスタンプで、このトークンがそれ以前には使用されるべきではない時刻を示す。JWT [RFC7519] で定義される。

sub

OPTIONAL。JWT [RFC7519] で定義されるトークンの Subject。通常、このトークンを承認した Resource Owner の機械可読な識別子である。

aud

OPTIONAL。JWT [RFC7519] で定義される、このトークンの意図された Audience を表すサービス固有の文字列識別子、または文字列識別子のリスト。

iss

OPTIONAL。JWT [RFC7519] で定義される、このトークンの issuer を表す文字列。

jti

OPTIONAL。JWT [RFC7519] で定義される、トークンの文字列識別子。

実装固有の応答名を、この JSON オブジェクトのトップレベル・メンバーとして追加してもよい（MAY）。ドメインを跨って使用されることを意図する応答名は、第3.1節で定義される "OAuth Token Introspection Response" レジストリに登録しなければならない（MUST）。

Authorization Server は、同一のリクエストであっても、呼び出し元の保護対象リソースによって応答を変えてもよい（MAY）。たとえば、保護対象リソースが自らの動作に不要な範囲までネットワーク全体について学習してしまうことを防ぐため、Authorization Server は、特定の保護対象リソースに対しては、あるトークンのスコープのうち返す範囲を制限してもよい（MAY）。

応答は、性能向上および introspection endpoint への負荷軽減のために保護対象リソースがキャッシュしてもよい（MAY）が、その代償として、保護対象リソースが認可判断に用いる情報の鮮度が低下する。応答をキャッシュする場合のトレードオフについては、第4節を参照。

例として、以下の応答はアクティブなトークンに関する情報一式を含む:

以下は非規範的な応答例である:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe",
  "scope": "read write dolphin",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "iss": "https://server.example.com/",
  "exp": 1419356238,
  "iat": 1419350238,
  "extension_field": "twenty-seven"
}

introspection の呼び出しが適切に認可されているにもかかわらず、トークンがアクティブではない、このサーバ上に存在しない、または保護対象リソースが当該トークンを introspect することを許可されていない場合、Authorization Server は "active" フィールドを "false" に設定した introspection response を返さなければならない（MUST）。Authorization Server の状態を第三者に過度に開示しないようにするため、Authorization Server は、なぜトークンが非アクティブなのかを含め、非アクティブなトークンに関する追加情報を含めるべきではない（SHOULD NOT）。

以下は、取り消しされた、またはその他の理由で無効なトークンに対する非規範的な応答例である:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": false
}

2.3. Error Response

保護対象リソースが OAuth 2.0 の client credentials を用いて introspection endpoint に認証し、その資格情報が無効である場合、Authorization Server は OAuth 2.0 [RFC6749] の第5.2節に記載のとおり HTTP 401（Unauthorized）を返す。

保護対象リソースが OAuth 2.0 bearer token を用いて introspection endpoint の呼び出しを認可し、認可に用いられたトークンに十分な権限が含まれない、または当該リクエストに対してその他の理由で無効である場合、Authorization Server は OAuth 2.0 Bearer Token Usage [RFC6750] の第3節に記載のとおり HTTP 401 を返す。

なお、適切に形成され認可されたクエリであっても、非アクティブまたはその他の理由で無効なトークン（あるいは、保護対象リソースが知ることを許可されていないトークン）に対する問い合わせは、本仕様では error response とは見なされない。その場合、Authorization Server は第2.2節に記載のとおり "active" フィールドを "false" に設定した introspection response を返さなければならない（MUST）。

3. IANA Considerations

3.1. OAuth Token Introspection Response Registry

本仕様は "OAuth Token Introspection Response" レジストリを確立する。

OAuth の登録クライアント・メタデータ名および説明は、oauth-ext-review@ietf.org メーリングリスト上での 2週間のレビュー期間を経て、1名以上の Designated Experts の助言にもとづき、Specification Required [RFC5226] により登録される。しかし、公開前であっても名称の割り当てを可能にするため、Designated Expert(s) は、その仕様が公開される見込みであると十分に満足した時点で登録を承認してもよい（MAY）。

レビューのためにメーリングリストへ送る登録申請は、適切な件名（例: "Request to register OAuth Token Introspection Response name: example"）を用いるべきである（SHOULD）。

レビュー期間内に、Designated Expert(s) は登録申請を承認または却下し、その決定をレビューリストおよび IANA に伝達する。却下の場合は、説明を含め、必要に応じて申請を成功させるための提案を示すべきである（SHOULD）。

IANA は、Designated Expert(s) からのレジストリ更新のみを受け付けなければならず（MUST）、登録申請のすべてをレビュー用メーリングリストへ誘導すべきである（SHOULD）。

3.1.1. Registration Template

Name

要求する名称（例: "example"）。この名称は大文字小文字を区別する。他の登録済み名称と大文字小文字を区別しない比較で一致する名称は受理されるべきではない（SHOULD NOT）。

また、[RFC7519] により確立された "JSON Web Token Claims" レジストリに登録された claim と一致する名称は、同程度の定義および意味論を持つべきである（SHOULD）。

Description

メタデータ値の簡潔な説明（例: "Example description"）。

Change controller

Standards Track RFC の場合は "IESG" と記載する。その他の文書の場合は責任主体の名称を記載する。その他の詳細（例: 郵送先住所、メールアドレス、ホームページ URI）を含めてもよい。

Specification document(s)

token endpoint の認可方法を規定する文書への参照。可能であれば、その文書のコピーを取得できる URI を含める。関連節の記載を含めてもよいが、必須ではない。

3.1.2. Initial Registry Contents

"OAuth Token Introspection Response" レジストリの初期内容は以下のとおり:

• Name: "active"\ Description: トークンのアクティブ状態\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "username"\ Description: Resource Owner のユーザー識別子\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "client_id"\ Description: client の client identifier\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "scope"\ Description: トークンで認可されたスコープ\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "token_type"\ Description: トークン種別\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "exp"\ Description: トークンの失効タイムスタンプ\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "iat"\ Description: トークンの発行タイムスタンプ\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "nbf"\ Description: それ以前にはトークンが有効ではないことを示すタイムスタンプ\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "sub"\ Description: トークンの Subject\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "aud"\ Description: トークンの Audience\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "iss"\ Description: トークンの issuer\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

• Name: "jti"\ Description: トークンの一意識別子\ Change Controller: IESG\ Specification Document(s): RFC 7662（本文書）の第2.2節。

---

4. Security Considerations

OAuth 2.0 システムの実装方法には多くの有効な選択肢があるため、Authorization Server がトークンが現在 "active" かどうかを判定する方法も多岐にわたる。しかし、token introspection を利用する Resource Server は、トークンの状態判定を Authorization Server に依存するため、Authorization Server はトークンの状態について適用可能なすべてのチェックを実行しなければならない（MUST）。たとえば、これらのテストには以下が含まれる:

• トークンが失効し得る場合、Authorization Server はトークンが期限切れかどうかを判定しなければならない（MUST）。
• トークンが使用可能になる前に発行され得る場合、Authorization Server はトークンの有効期間が開始しているかどうかを判定しなければならない（MUST）。
• トークンが発行後に取り消しされ得る場合、Authorization Server はその取り消しが行われたかどうかを判定しなければならない（MUST）。
• トークンに署名がある場合、Authorization Server は署名を検証しなければならない（MUST）。
• トークンが特定の Resource Server でのみ使用できる場合、Authorization Server は、introspection を呼び出した Resource Server で当該トークンが使用可能かどうかを判定しなければならない（MUST）。

Authorization Server が適用可能なチェックを実行し損ねると、Resource Server はその応答に基づいて誤ったセキュリティ判断を行い得る。なお、これらのチェックのすべてがすべての OAuth 2.0 導入に適用されるわけではなく、どのチェック（およびその他のチェック）が適用されるかは Authorization Server が決定する。

保護もスロットリングもされていない場合、introspection endpoint は、攻撃者が多数の候補トークン値を順に照会し、有効なトークンを探り当てる手段となり得る。これを防ぐため、Authorization Server は、introspection endpoint にアクセスする必要がある保護対象リソースに対して認証を必ず要求し（MUST）、さらに保護対象リソースが introspection endpoint を呼び出すことを明示的に許可されることを要求すべきである（SHOULD）。そのような認証資格情報の詳細は本仕様の対象外だが、一般には、token endpoint で用いる有効な client 認証機構、OAuth 2.0 Access Token、あるいはその他の HTTP の認可・認証メカニズムなどがあり得る。

ひとつのソフトウェアが client と保護対象リソースの両方として動作する場合、token endpoint と introspection endpoint の間で同じ資格情報を再利用してもよい（MAY）が、その場合、ソフトウェア内の client 部分と保護対象リソース部分の活動が混同される可能性があり、Authorization Server は各モードごとに別の資格情報を要求してもよい（MAY）。

introspection endpoint は OAuth 2.0 トークンをパラメータとして受け取り、認可判断に用いられる情報を返すため、サーバは Transport Layer Security (TLS) 1.2 [RFC5246] をサポートしなければならず（MUST）、そのセキュリティ要件を満たす追加のトランスポート層機構をサポートしてもよい（MAY）。TLS を使用する場合、client または保護対象リソースは、[RFC6125] に記載のとおり TLS/SSL のサーバ証明書チェックを実行しなければならない（MUST）。実装上のセキュリティ考慮事項は Recommendations for Secure Use of TLS and DTLS [BCP195] にある。

Access Token の値がクエリ・パラメータ経由でサーバ側ログに漏れるのを防ぐため、トークン introspection を提供する Authorization Server は、introspection endpoint における HTTP GET の使用を許可しないようにしてもよく（MAY）、代わりに introspection endpoint では HTTP POST の使用を要求してもよい（MAY）。

Authorization Server の内部状態の開示を避けるため、非アクティブなトークンに対する introspection response は、必須の "active" claim（値を "false" に設定）以外の追加 claim を含めるべきではない（SHOULD NOT）。

保護対象リソースは introspection endpoint の応答をキャッシュしてもよい（MAY）ため、このプロトコルを用いる OAuth 2.0 システムの設計者は、このようなセキュリティ情報をキャッシュすることに伴う性能とセキュリティのトレードオフを考慮しなければならない（MUST）。

• タイムアウトを短くした控えめなキャッシュは、より最新の情報を提供する（より頻繁な照会が必要になる）一方で、ネットワーク・トラフィックと introspection endpoint への負荷を増やす。
• 期間の長い積極的なキャッシュはトラフィックと負荷を最小化するが、トークンに関する情報が古くなるリスクがある。

たとえば、保護対象リソースがキャッシュされた応答値に基づいて認可判断を行っている間に、トークンが取り消しされる可能性がある。この結果、取り消し済みトークンが保護対象リソースで使用できてしまう時間窓が生まれる。したがって、許容可能なキャッシュ有効期間は、アクセスされる保護対象リソースの懸念事項や機微性、およびトークンが中間期間に取り消し・無効化される可能性を踏まえて慎重に検討する必要がある。

高い機微性を持つ環境では、保護対象リソース側でキャッシュを完全に無効化し、古いキャッシュ情報のリスクを完全に排除する選択も可能であるが、その代償としてネットワーク・トラフィックとサーバ負荷は増加する。

応答に "exp" パラメータ（失効時刻）が含まれる場合、応答はそこで示される時刻以降にキャッシュしてはならない（MUST NOT）。

トークン introspection を提供する Authorization Server は、この呼び出しで提示されるトークン値を解釈できなければならない。その正確な方法は実装詳細であり、本仕様の対象外である。

• 非構造化トークンの場合、これはトークンのコンテキスト情報を含むデータストアに対する単純なサーバ側データベース照会という形を取り得る。
• 構造化トークンの場合、サーバがトークンを解析し、署名やその他の保護機構を検証し、トークンに含まれる情報を保護対象リソースへ返すという形を取り得る（これにより、client と同様に保護対象リソースはトークン内容を意識しなくてよい）。

なお、introspection の過程で必要な暗号化情報を含むトークンについては、Authorization Server はその情報へアクセスするためにトークンを復号し検証できなければならない。

また、Authorization Server がトークンに関する情報を一切保存しておらず、トークン自体を解析して情報へアクセスする手段もない場合、introspection サービスを提供できる可能性は低い。

---

5. Privacy Considerations

introspection response には、Resource Owner のユーザー識別子など、プライバシー上機微な情報が含まれる可能性がある。その場合、意図しない相手への情報開示を防ぐための対策を必ず講じなければならない（MUST）。一つの方法として、ユーザー識別子を不透明なサービス固有の文字列として送信し、保護対象リソースごとに異なる識別子を返すことが考えられる。

本仕様の拡張として、保護対象リソースが（たとえばクライアントの IP アドレスなど）クライアントのリクエストに関する追加情報を Authorization Server に送信する場合、その情報には追加のプライバシー考慮事項があり得るため、拡張仕様はそれを詳述すべきである（SHOULD）。しかし、そのような拡張の性質および含意は本仕様の対象外である。

introspection response からプライバシー上機微な情報を省くことは、プライバシー問題を最小化する最も簡単な方法である。

---

6. References

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246,
           DOI 10.17487/RFC5246, August 2008,
           <http://www.rfc-editor.org/info/rfc5246>.

[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
           Verification of Domain-Based Application Service Identity
           within Internet Public Key Infrastructure Using X.509
           (PKIX) Certificates in the Context of Transport Layer
           Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
           2011, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
           RFC 6749, DOI 10.17487/RFC6749, October 2012,
           <http://www.rfc-editor.org/info/rfc6749>.

[RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
           Framework: Bearer Token Usage", RFC 6750,
           DOI 10.17487/RFC6750, October 2012,
           <http://www.rfc-editor.org/info/rfc6750>.

[RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
           2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
           August 2013, <http://www.rfc-editor.org/info/rfc7009>.

[RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
           2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           DOI 10.17487/RFC7231, June 2014,
           <http://www.rfc-editor.org/info/rfc7231>.

[RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
           (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
           <http://www.rfc-editor.org/info/rfc7519>.

[W3C.REC-html5-20141028]
           Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
           Navara, E., 0'Connor, E., and S. Pfeiffer, "HTML5", World
           Wide Web Consortium Recommendation
           REC-html5-20141028, October 2014,
           <http://www.w3.org/TR/2014/REC-html5-20141028>.

6.2. Informative References

[BCP195]   Sheffer, Y., Holz, R., and P. Saint-Andre,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 7525, May 2015,
           <http://www.rfc-editor.org/info/bcp195>.

---

Appendix A. Use with Proof-of-Possession Tokens

OAuth 2.0 Bearer Token Usage [RFC6750] で定義される bearer token のようなものでは、保護対象リソースは、introspection サービスへ提出するためにトークンの秘密部分全体を保持している。しかし、Proof-of-Possession 形式のトークンでは、保護対象リソースが保持するのは、リクエスト中に使用されるトークン識別子と、リクエストに対する暗号学的署名のみである。

リクエスト上の署名を検証するために、保護対象リソースは、Authorization Server の introspection endpoint にトークン識別子を提出して、そのトークンに必要な鍵情報を取得できる可能性がある。この利用の詳細は本仕様の対象外であり、Proof-of-Possession トークンの定義と併せて、本仕様の拡張として定義される。

---

Acknowledgements

本文書へのフィードバックおよびレビューを行った OAuth Working Group と User Managed Access Working Group に感謝する。また、本仕様の client および server コンポーネントの実装者各位にも感謝する。

特に、著者は Amanda Anganes、John Bradley、Thomas Broyer、Brian Campbell、George Fletcher、Paul Freemantle、Thomas Hardjono、Eve Maler、Josh Mandel、Steve Moore、Mike Schwartz、Prabath Siriwardena、Sarah Squire、Hannes Tschofennig に感謝する。

---

Author's Address

Justin Richer (editor)

Email: ietf@justin.richer.org