APIゲートウェイ・バック・エンドとしてのログインの追加

コンソールを使用してログイン・バック・エンドをAPIデプロイメント仕様に追加するには:

1. コンソールを使用してAPIデプロイメントを作成または更新したり、「デプロイメントの作成」オプションを選択して、「基本の情報」ページで詳細を入力します。

   詳細は、APIデプロイの作成によるAPIゲートウェイのAPIのデプロイおよびAPIゲートウェイの更新を参照してください

2. 「認証」ページで、認証オプションを指定します:

   1. トークン認証リクエスト・ポリシーを構成し、「検証タイプ」リストから「OAuth 2.0イントロスペクション・エンドポイント」を選択します。
   2. 検証失敗ポリシーを構成し、「アイデンティティ・プロバイダへのOAuth2.0リダイレクト・クライアント」を選択します。
   3. 「ログイン・パス」には、静的ログイン・リダイレクト・パス(/auth/callbackなど)を指定します。

      静的ログイン・リダイレクト・パスは、デプロイメント・パス接頭辞からの相対パスである必要があります。たとえば、デプロイメント・パス接頭辞が/apexで、静的ログイン・リダイレクト・パスが/auth/callbackの場合、フル・コールバック・パスは/apex/auth/callbackです。

   認証オプションの詳細は、APIデプロイメントへの認証と認可を追加およびAPIデプロイメントへの認証と認可を追加するためのトークンの検証を参照してください

3. 「ルート」ページで、新しいルートを作成し、次を指定します:

   • パス: OAuth 2.0検証失敗ポリシーで指定した静的ログイン・リダイレクト・パス。指定するルート・パスで次の点に注意してください:

     • デプロイメント・パス接頭辞に対して相対的です
     • 後にスラッシュ(/)を付ける必要があります
     • 複数のスラッシュを含めることができます(隣接していない場合)
     • 英数字の大文字と小文字を使用できます
     • 特殊文字$ - _ . + ! ' ( ) , % ; : @ & =を使用できます
     • パス・パラメータまたはワイルドカードを含めることはできません

     ログイン・バック・エンド・ルート・パスのルールは、ログアウト・バック・エンド・ルート・パスのルールとは異なります。

   • メソッド: バックエンドが受け入れた1つ以上のメソッド。ログイン・バック・エンドの場合、GETのみが受け入れられます。

   • 単一のバックエンドの追加または複数のバックエンドの追加: すべてのリクエストを同じバックエンドにルーティングするか、リクエストを異なるバックエンドにルーティングするか。

     次の手順では、単一のバックエンドを使用することを前提にしているため、「単一のバックエンドの追加」を選択します。別のバックエンドを使用する場合は、「複数のバックエンドの追加」を選択します。

   • バックエンド・タイプ: バックエンド・サービスのタイプ(ログイン)。

4. 「作成」を選択してルートを作成します。

5. 「次」を選択して、APIデプロイメント用に入力した詳細を確認します。

6. APIデプロイメントを作成または更新する場合は、「作成」または「更新」を選択します。

7. アイデンティティ・プロバイダを構成して、完全なコールバックURLを有効なリダイレクトURLとして含めます。

   フル・コールバックURLには、APIゲートウェイのホスト名、デプロイメント・パス接頭辞および静的ログイン・リダイレクト・パスが含まれます。例:

   https://<gateway-hostname>/<deployment-path-prefix>/auth/callback

   デプロイメント・パス接頭辞が単純に/で、静的ログイン・リダイレクト・パスが/auth/callbackの場合、完全なコールバックURLはhttps://<gateway-hostname>/auth/callback (https://<gateway-hostname>//auth/callbackではなく)です。

8. オプションで、APIをコールして、APIが正常にデプロイされていることを確認します。

JSONファイルのAPIデプロイメント仕様にログイン・バック・エンドを追加するには:

1. デフォルトのJSONエディタを使用して、ログイン・バック・エンドを追加する既存のAPIデプロイメント仕様を編集するか、新しいAPIデプロイメント仕様を作成します。

   たとえば、次の基本的なAPIデプロイメント仕様では、Oracle Functionsの単純なHello Worldサーバーレス・ファンクションを単一のバック・エンドとして定義しています:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

2. routesセクションに、ログイン・バック・エンドの新しいセクションを含めます。

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       },
       {
         "path": "<login-route-path>",
         "methods": ["<method-list>"],
         "backend": {
           "type": "OAUTH2_LOGIN_BACKEND"
         }
       }
     ]
   }

   ここでは:

   • <login-route-path>は、アイデンティティ・プロバイダからログイン・バック・エンドへのリダイレクトのパスを指定します。パスは、OAuth 2.0検証失敗ポリシーで構成された静的ログイン・リダイレクト・パスと一致する必要があります。指定するルート・パスで次の点に注意してください:

     • デプロイメント・パス接頭辞に対して相対的です
     • 後にスラッシュ(/)を付ける必要があります
     • 複数のスラッシュを含めることができます(隣接していない場合)
     • 英数字の大文字と小文字を使用できます
     • 特殊文字$ - _ . + ! ' ( ) , % ; : @ & =を使用できます
     • パス・パラメータまたはワイルドカードを含めることはできません

     ログイン・バック・エンド・ルート・パスのルールは、ログアウト・バック・エンド・ルート・パスのルールとは異なります。

   • <method-list>は、ログイン・バック・エンドによって受け入れられる1つ以上のメソッドをカンマで区切って指定します。ログイン・バック・エンドの場合、GETのみが受け入れられます。

   • "type": "OAUTH2_LOGIN_BACKEND"は、バック・エンドがログイン・バック・エンドであることを指定します。

3. APIデプロイメント仕様を含むJSONファイルを保存します。

4. APIデプロイメント仕様は、次の方法でAPIデプロイメントを作成または更新するときに使用します:

   • 「既存のデプロイメントAPIのアップロード」オプションを選択したときに、コンソールでJSONファイルを指定します
   • APIゲートウェイREST APIへのリクエストでJSONファイルを指定します

   詳細は、APIデプロイの作成によるAPIゲートウェイのAPIのデプロイおよびAPIゲートウェイの更新を参照してください

5. アイデンティティ・プロバイダを構成して、完全なコールバックURLを有効なリダイレクトURLとして含めます。

   フル・コールバックURLには、APIゲートウェイのホスト名、デプロイメント・パス接頭辞および静的ログイン・リダイレクト・パスが含まれます。例:

   https://<gateway-hostname>/<deployment-path-prefix>/auth/callback

   デプロイメント・パス接頭辞が単純に/で、静的ログイン・リダイレクト・パスが/auth/callbackの場合、完全なコールバックURLはhttps://<gateway-hostname>/auth/callback (https://<gateway-hostname>//auth/callbackではなく)です。

6. (オプション) APIをコールして、APIが正常にデプロイされていることを確認します。APIゲートウェイにデプロイされたAPIのコールを参照してください。