OpenID Connect のイントロスペクション・エンドポイントの起動

イントロスペクション・エンドポイントにより、アクセス・トークン保有者は、 アクセス・トークンに関するメタデータのセットをそのアクセス・トークンを発行した OpenID Connect プロバイダーから要求することができます。アクセス・トークンは、OpenID Connect または OAuth 認証を介して取得されたものでなければなりません。

始める前に

リソース・サービスまたはクライアント・アプリケーションがイントロスペクション・エンドポイントを起動する場合、 そのリソース・サービスまたはクライアント・アプリケーションは、自身を正規 OAuth 2.0 クライアントとして OpenID Connect サーバーに登録する必要があります。登録されたクライアントのメタデータは属性 introspectTokens = true を含んでいる必要があります。

このタスクについて

OpenID Connect および OAuth 2.0 で使用されるアクセス・トークンに含まれる情報は、クライアントにとっては不透明です。これにより、 保護リソースまたはクライアントは、アクセス・トークンに関して OpenID Connect プロバイダーから返されるメタデータに基づいて、 認可決定を行うことができます。

OpenID Connect が有効になった Liberty サーバーは、以下の URL で OpenID Connect イントロスペクション・エンドポイントにアクセスできます。

 https://server.example.com:443/oidc/endpoint/<provider_name>/introspect
トラブルの回避: アウトバウンド・プロキシーを使用している場合、プロキシー・ホストを介して要求を自動的に転送する手段は OpenID Connect RP では提供されないことに注意してください。

OpenID Connect プロバイダー (OP) へのアクセスにプロキシーを使用する必要がある場合は、OP 関連の URL プロパティーに入力する値には、外部 OP のホストおよびポートではなく、プロキシーのホストおよびポートが含まれる必要があります。

ほとんどの場合、OP のホストおよびポートを、プロキシーのホストおよびポートに置き換えることができます。入力する URL は、RP およびクライアント (ブラウザーまたはアプリケーション) の両方に可視でなければなりません。使用する正しい URL を決定する方法について詳しくは、プロキシー管理者にお問い合わせください。

この例では、クライアントは SSL ポートが 443 に設定されると予期しています。

手順

  1. 登録された OpenID Connect Client のクライアント ID とパスワードを GET 要求または POST 要求の HTTP Basic Authorization ヘッダーに入れて、 クライアント認証をセットアップします。 クライアント ID およびパスワードは、application/x-www-form-urlencoded エンコード・アルゴリズムを使用してエンコードされます。エンコードされたクライアント ID がユーザー名として使用され、 エンコードされたパスワードがパスワードとして使用されます。
  2. アクセス・トークンのストリング値を、イントロスペクション・エンドポイントへの GET 要求または POST 要求にパラメーターとして組み込みます。
  3. GET 要求または POST 要求をイントロスペクション・エンドポイントに送信します。

タスクの結果

上の手順を完了すると、『例』セクションに示されているように、イントロスペクション・エンドポイントに送信される有効な HTTP 要求が生成されます。

要求が有効であれば、 イントロスペクション・エンドポイントは、application/json フォーマットの JSON オブジェクトとともに HTTP 200 応答を返し、 このオブジェクトには、アクセス・トークンがアクティブなのか有効期限が切れているのかに基づいて、 以下の情報が含まれます。

アクセス・トークンがアクティブである場合、エンドポイントは active:true および以下の追加情報を JSON オブジェクトに入れて返します。

  • active: アクセス・トークンがアクティブかどうかを示すブール値。
  • client_id: アクセス・トークンを要求した OpenID Connect Client のクライアント ID。
  • sub: アクセス・トークンを認可したリソース所有者。
  • scope: アクセス・トークンと関連付けられたスコープのリスト (各スコープを空白で区切ったリスト)。
  • iat: アクセス・トークンがいつ発行されたのかを示す、1970 年 1 月 1 日 (UTC) 以降の秒単位で計測された整数タイム・スタンプ。
  • exp: アクセス・トークンがいつ有効期限切れになるのかを示す、1970 年 1 月 1 日 (UTC) 以降の秒単位で計測された整数タイム・スタンプ。
  • realmName: リソース所有者のレルム名。
  • uniqueSecurityName: リソース所有者の固有セキュリティー名。
  • tokenType: アクセス・トークンのタイプ。OpenID Connect では、この値は Bearer です。
  • grant_type: アクセス・トークンを生成した権限付与のタイプを示すストリング。可能な値は、authorization_codepasswordrefresh_tokenclient_credentialsresource_ownerimplicit、 および urn:ietf:params:oauth:grant-type:jwt-bearer です。

アクセス・トークンの有効期限が切れているが、 提供された認証が有効な場合、または、提供されたアクセス・トークンのタイプが誤っている場合、 エンドポイントは JSON オブジェクトに入れて active:false を返します。

注: クライアントまたはリソース・サービスがアクセス・トークンのイントロスペクションを実行するには、 クライアントまたはリソース・サービスは、自身をクライアントとして OpenID Connect プロバイダーに登録する必要があり、 クライアント・メタデータでは introspect_tokenstrue に設定されていなければなりません。

以下に、要求の例と、アクティブなアクセス・トークンおよび有効期限が切れたアクセス・トークンの例を示します。

要求例は次のとおりです。

  POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
     token=SOYleDziTitHeKcodp6vqEmRwKPjz3lFZTcsQtVC

アクセス・トークンがアクティブな場合の応答例を以下に示します。

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
{  
   "exp"                : 1415307710,
   "realmName"          : "BasicRealm",
   "sub"                : "testuser",
   "scope"              : "openid scope2 scope1",
   "grant_type"         : "authorization_code",
   "uniqueSecurityName" : "testuser",
   "active"             : true,
   "token_type"         : "Bearer",
   "client_id"          : "pclient01",
   "iat"                : 1415307700
}

アクセス・トークンの有効期限が切れている場合の応答例を以下に示します。

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 {
     "active":"false"
 }

トピックのタイプを示すアイコン タスク・トピック

ファイル名: twlp_oidc_introspection_endpoint.html