- トークン全般
- アクセストークン
- リフレッシュトークン
- ID トークン
- 所持証明 (PoP) トークン
- 認可タイプ
- スコープ
- PKCE (RFC 7636)
- クライアント管理
- 認可リクエスト
- ユーザー認証
- エラー処理
- クライアント認証
-
イントロスペクション
- 期限切れのアクセストークンに関するイントロスペクションの挙動
- アクセストークンがカバーするスコープの確認
- Bearer error="invalid_request" という responseContent について
- 2 種類のイントロスペクション API の使い分け
- Userinfo エンドポイント
- JARM
- デバイスフロー (RFC 8628)
2 種類のイントロスペクション API の使い分け
はじめに
本記事では、Authlete が提供する 2 種類のイントロスペクション API と、それらの使い分けについて説明します。
Authlete が提供するイントロスペクション API
トークンのイントロスペクション機能として、Authlete は次の 2 種類の API を提供しています。
以下に概要を示します。
/auth/introspection API
/auth/introspection API は Authlete 独自の API です。リソースサーバー (RS) の「protected resource endpoint (いわゆる Web API)」の実装の中から呼び出されることを想定しています。
リクエストパラメーターとして、アクセストークンに加え、そのトークンにひもづいていることが期待される scope や subject、クライアント証明書を指定し、Authlete にその検証を依頼できます。これにより、RS での実装の手間が低減されます。
/auth/introspection/standard API
/auth/introspection/standard API は認可サーバー (AS) の「RFC 7662 準拠の introspection endpoint」の実装の中から呼び出されることを想定しています。
RS は RFC 7662 準拠のイントロスペクション機能を利用できるようになります。また AS は、Authlete の API キー / シークレットを RS と共有する必要がありません。
どちらのイントロスペクション API を用いるべきか
2 種類のイントロスペクション API のどちらを用いるかは、AS / RS / Authlete の各サービスの間をどの程度密結合・疎結合にするかによります。主なユースケースと、各ケースに適した API を、以下に例示します。
RS が Authlete と直接通信する場合
RS が Authlete の API キー / シークレットを保有できる場合には、それを用いて RS 自身が Authlete の /auth/introspection API を呼び出すのが最もシンプルです。

クライアントからの API アクセスを API ゲートウェイに集約する場合
API ゲートウェイが、AS のエンドポイントの一部(トークンエンドポイントなど)とRS の API エンドポイントの両方を扱う場合には、その API ゲートウェイは必然的に Authlete の API キー / シークレットを保有することになります。
よって前述のケースと同様に、/auth/introspection API を用いるのが最もシンプルな構成となります。

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

How did we do with this article?