1. はじめに

OAuth 2.0 [RFC6749] において、トークンの内容はクライアントに対して不透明です。これは、クライアントがトークン自体の内容や構造について何も知る必要がないことを意味します (もしあれば)。しかし、トークンには依然として大量のメタデータが付加される可能性があります。例えば、現在の有効性、承認されたスコープ、およびトークンが発行されたコンテキストに関する情報などです。これらの情報は、提示されたトークンに基づいて保護されたリソースが認可決定を行う際に、しばしば極めて重要です。OAuth 2.0 は、リソースサーバーが認可サーバーから受け取ったトークンに関するメタ情報を取得するためのプロトコルを定義していないため、このギャップを埋めるためにいくつかの異なるアプローチが開発されてきました。これには、JWT [RFC7519] などの構造化トークン形式の使用や、トークン情報を伝達する独自のサービス間通信メカニズム (共有データベースや保護されたエンタープライズサービスバスなど) の使用が含まれます。

この仕様は、認可された保護されたリソースが認可サーバーにクエリを実行して、OAuth 2.0 クライアントによって提示された特定のトークンのメタデータのセットを決定できるようにするプロトコルを定義します。このメタデータには、トークンが現在アクティブであるかどうか (または期限切れまたは何らかの方法で取り消されたか)、トークンが持つアクセス権 (通常は OAuth 2.0 スコープを通じて伝達される)、およびトークンが許可された認可コンテキスト (トークンを認可したユーザーとトークンが発行されたクライアントを含む) が含まれます。トークンイントロスペクションにより、保護されたリソースは、トークン自体にこの情報が含まれているかどうかに関係なくこの情報をクエリできるため、この方法を構造化トークン値と併用したり、独立して使用したりできます。さらに、保護されたリソースは、この仕様で説明されているメカニズムを使用して、特定の認可決定コンテキストでトークンをイントロスペクトし、この認可決定を適切に行うためにトークンに関する関連メタデータを確認できます。

1.1. 表記規則

この文書内のキーワード 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', および 'OPTIONAL' は、[RFC2119] で説明されているように解釈されるものとします。

特に明記しない限り、すべてのプロトコルパラメータ名と値は大文字と小文字を区別します。

1.2. 用語

このセクションは、この仕様で使用される用語を定義します。このセクションは、この仕様の規範的な部分であり、実装に要件を課します。

この仕様では、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 (イントロスペクションエンドポイント) : トークンイントロスペクション操作が実行される OAuth 2.0 エンドポイント。