第5章 ActiveDocs と OAuth
ActiveDocs により、ユーザーは 1 つの設定画面から OAuth 対応の API をテストして呼び出すことができます。
前提条件
- Red Hat Single Sign-On インスタンスおよび OpenID Connect インテグレーションを設定しておく必要があります。設定方法の詳細は、OpenID Connect インテグレーション のドキュメントを参照してください。
- また、ActiveDocs の設定方法を十分理解する必要もあります。3scale への ActiveDocs の追加 および OpenAPI 仕様の作成 を参照してください。
5.1. 3scale 仕様でのクライアントクレデンシャルおよびリソースオーナーフローの例 リンクのコピーリンクがクリップボードにコピーされました!
この最初の例は、3scale 仕様の OAuth 2.0 クライアントクレデンシャルフローを使用する API に関するものです。この API は任意のパスを受け入れ、リクエストに関する情報 (パス、リクエストパラメーター、ヘッダー等) を返します。Echo API には、有効なアクセストークンを使用する場合に限りアクセスできまます。API のユーザーは、クレデンシャル (client_id および ) を交換してアクセストークンを取得するまで、API を呼び出すことができません。
client_secret
ユーザーが 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 エンドポイントが最初に表示されるよう順番を指定する必要があるため、以下のようになります。