> ## Documentation Index
> Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 2 種類のイントロスペクション API の使い分け

> Authleteが提供する2種類のイントロスペクションAPIと、それらの使い分けについて説明。

## はじめに

本記事では、Authlete が提供する 2 種類のイントロスペクション API と、それらの使い分けについて説明します。

## Authlete が提供するイントロスペクション API

トークンのイントロスペクション機能として、Authlete は次の 2 種類の API を提供しています。

* [/auth/introspection](/api-reference/introspection-endpoint/process-introspection-request) API
* [/auth/introspection/standard](/api-reference/introspection-endpoint/process-oauth-20-introspection-request) API

以下に概要を示します。

### /auth/introspection API

/auth/introspection API は Authlete 独自の API です。リソースサーバー (RS) の「protected resource endpoint (いわゆる Web API)」の実装の中から呼び出されることを想定しています。

RS はリクエストパラメーターとして、アクセストークンに加え、そのトークンにひもづいていることが期待される [scope](/ja/configuration-reference/endpoints/checking-if-an-access-token-has-particular-scopes) や subject、[クライアント証明書](/ja/configuration-reference/tokens-and-claims/issuing-mutual-tls-certificate-bound-access-tokens)、[DPoP Proof JWT](/ja/configuration-reference/tokens-and-claims/using-dpop) などを指定し、Authlete にその検証を依頼できます。これにより、RS での実装の手間が低減されます。

### /auth/introspection/standard API

/auth/introspection/standard API は認可サーバー (AS) の「RFC 7662 準拠の introspection endpoint」の実装の中から呼び出されることを想定しています。

RS からイントロスペクションリクエストを受信した AS は、その内容をリクエストパラメーターとして Authlete に送信します。Authlete は RFC 7662 に従って処理を行い、イントロスペクションレスポンスの内容を生成し、AS に返却します。

## どちらのイントロスペクション API を用いるべきか

2 種類のイントロスペクション API のどちらを用いるかは、AS / RS / Authlete の各サービスの間をどの程度密結合・疎結合にするかによります。主なユースケースと、各ケースに適した API を、以下に例示します。

### RS が Authlete と直接通信する場合

RS が Authlete のサービスアクセストークンを保有できる場合には、それを用いて RS 自身が Authlete の /auth/introspection API を呼び出すのが最もシンプルです。なお Authlete バージョン 3.0.31 以降では、[カスタムサービストークン](https://www.authlete.com/ja/developers/relnotes/3.0-2026-april/#カスタムサービストークン)機能を利用し、RS が保有するサービスアクセストークンの権限をイントロスペクションのみに限定できます。

<img src="https://mintcdn.com/authlete/WGQFc11Y4wUplGrc/ja/configuration-reference/endpoints/two-introspection-apis-1_ja.png?fit=max&auto=format&n=WGQFc11Y4wUplGrc&q=85&s=fe84f67af7687c57fc9cf13224ffc112" alt="two-introspection-apis-1_ja" width="1920" height="1080" data-path="ja/configuration-reference/endpoints/two-introspection-apis-1_ja.png" />

### クライアントからの API アクセスを API ゲートウェイに集約する場合

API ゲートウェイが、AS のエンドポイントの一部（トークンエンドポイントなど）とRS の API エンドポイントの両方を扱う場合には、その API ゲートウェイは必然的に Authlete のサービスアクセストークンを保有することになります。

よって前述のケースと同様に、/auth/introspection API を用いるのが最もシンプルな構成となります。

<img src="https://mintcdn.com/authlete/WGQFc11Y4wUplGrc/ja/configuration-reference/endpoints/two-introspection-apis-2_ja.png?fit=max&auto=format&n=WGQFc11Y4wUplGrc&q=85&s=d30c40310accc8fc33368780be7b9805" alt="two-introspection-apis-2_ja" width="1920" height="1080" data-path="ja/configuration-reference/endpoints/two-introspection-apis-2_ja.png" />

### RS に RFC 7662 準拠のイントロスペクション API を提供する場合

RS から Authlete への通信をしない・避けたい、あるいは AS と RS とを完全に分離したい場合には、AS が RFC 7662 準拠のイントロスペクション API を RS に提供し、AS が Authlete の /auth/introspection/standard API を呼び出すようにすると良いでしょう。

<img src="https://mintcdn.com/authlete/WGQFc11Y4wUplGrc/ja/configuration-reference/endpoints/two-introspection-apis-3_ja.png?fit=max&auto=format&n=WGQFc11Y4wUplGrc&q=85&s=3a2163941a3d9eb4a27e3ad67729160a" alt="two-introspection-apis-3_ja" width="1920" height="1080" data-path="ja/configuration-reference/endpoints/two-introspection-apis-3_ja.png" />
