第5章 ActiveDocs と OAuth
ActiveDocs により、ユーザーは 1 つの設定画面から OAuth 対応の API をテストして呼び出すことができます。
前提条件
- Red Hat Single Sign-On または Red Hat build of Keycloak インスタンスをセットアップし、OpenID Connect インテグレーションを設定した。設定方法の詳細は、OpenID Connect インテグレーション に関するドキュメントを参照してください。
- また、ActiveDocs の設定方法を十分理解する必要もあります。3scale への ActiveDocs の追加 および OpenAPI Specification の作成 を参照してください。
5.1. 3scale API Management 仕様でのクライアント認証情報およびリソースオーナーフローの例 リンクのコピーリンクがクリップボードにコピーされました!
この最初の例は、3scale 仕様の OAuth 2.0 クライアント認証情報フローを使用する API に関するものです。この API は任意のパスを受け入れ、リクエストに関する情報 (パス、リクエストパラメーター、ヘッダーなど) を返します。Echo API には、有効なアクセストークンを使用する場合に限りアクセスできまます。API のユーザーは、認証情報 (client_id および client_secret) を交換してアクセストークンを取得するまで、API を呼び出すことができません。
ユーザーが ActiveDocs から API を呼び出せるようにするには、アクセストークンを要求する必要があります。これは単なる OAuth 承認サーバーへの呼び出しなので、OAuth トークンエンドポイント用の ActiveDocs 仕様を作成できます。これにより、ActiveDocs 内からこのエンドポイントへの呼び出しが可能になります。この例のクライアント認証情報フローの場合、Swagger JSON 仕様は以下のようになります。
リソースオーナー OAuth フローでは、ユーザー名とパスワードのパラメーターおよびアクセストークンを発行するために必要なその他のパラメーターを追加する必要があります。このクライアント認証情報フローの例では、client_id と client_secret (サインイン済みユーザーの 3scale の値を代入可能)、ならびに grant_type を送信しています。
次に、Echo API の ActiveDocs 仕様で、client_id と client_secret の代わりに access_token パラメーターを追加します。
その後は、通常どおり開発者ポータルに ActiveDocs を含めることができます。この場合、OAuth エンドポイントが最初に表示されるよう順番を指定する必要があるため、以下のようになります。