OAuth 2.0 トークン内省

OAuth 2.0 トークン内省は、OAuth クライアントによって提供される特定のトークン（アクセストークンまたはリフレッシュトークン）に関連付けられたメタデータを決定するために、認可された保護リソースが認可サーバーに問い合わせることを可能にする方法を定義しています。この特定のトークンのメタデータに基づいて、リソース所有者は保護されたリソースにアクセスすることができます。

このメタデータには以下が含まれます：

• トークンが現在アクティブであるかどうか（または期限切れや取り消されているかどうか）
• アクセストークンが付与する権限（通常は OAuth 2.0 スコープを通じて伝達されます）
• トークンが付与された認可コンテキスト（誰がトークンを認可し、どのクライアントに発行されたかを含む）

トークン内省は、トークン自体に情報が含まれているかどうかにかかわらず、保護されたリソースがこの情報を問い合わせる能力を提供します。

アクセストークンには、エンコード方法に応じて2種類あります：

• 識別子ベース: トークンは、認可サーバーのデータベースにある認可に関連付けられたランダムで推測困難な識別子を表します。
• 自己完結型: 認可はトークン自体にエンコードされており、改ざんを防ぐために暗号化で保護されています。この方法の一般的な標準は JSON Web Token (JWT) です。

自己完結型トークンの場合、アクセス トークンから直接認可関連メタデータを解析することができます。しかし、識別子ベースのトークンの場合は、メタデータを検証/取得するために認可サーバーのトークン内省機能を使用する必要があります。

トークン内省リクエスト#

識別子ベースのアクセストークンを使用するには、ネットワークリクエストを介して認可サーバーでの検証が必要です。これに関する標準プロトコルは、OAuth 2.0 トークン内省 (RFC 7662) と呼ばれます。

保護されたリソースは、トークンを認可サーバーの内省エンドポイントに POST し、結果としてトークンのパラメータを含む JSON オブジェクトを受け取ります。

内省リクエストは任意に開始することはできないことに注意してください。それらは次のいずれかの条件を満たす必要があります：

• 資格情報を使用した認証（認可サーバーに事前登録されている必要があります）、または
• アクセストークンを使用した認可。

結果として、この特定の相互作用では、保護されたリソースが OAuth クライアントとなり、認可サーバーが保護されたリソースとなります。

以下は、保護されたリソースが認可サーバーに OAuth クライアントとして登録した後に取得したクライアント ID とクライアントシークレットを使用して認証する内省リクエストの例です。

以下は、アクセストークンを直接使用する内省リクエストの例です。アクセストークンは、登録済みのマシン間アプリとクライアント資格情報付与タイプを使用して /token エンドポイントから直接取得できます。

トークン内省レスポンス#

最も重要なパラメータは active で、これはブール値です。true の場合、トークンが有効であることを示し、JSON オブジェクトにはスコープ値などの他のトークン詳細が含まれます。false の場合、トークンは無効か期限切れであり、保護されたリソースは invalid_token エラーコードで401 Unauthorized レスポンスを返す必要があります。

以下は、有効なトークンの例レスポンスです：

必須である active を除き、他のすべてのパラメータはオプションです。

保護されたリソースは、JWT アクセストークンを解析および検証する方法と同様に、これらの追加フィールドを使用してアクセス権限を決定することができます。