すべてのプロダクト
Search

このプロダクト

    Microservices Engine:OIDC 認証の設定

    ドキュメントセンター

    Microservices Engine:OIDC 認証の設定

    最終更新日:Jul 01, 2026

    企業の認証システムと OpenID Connect (OIDC) プロトコルを統合することで、内部サービスの認証と認可を一元的に管理できます。このアプローチにより、認証プロセスが簡素化され、繰り返し行われる統合作業が削減されます。Cloud-native Gateway は、統一された認証を提供してシステムのセキュリティを強化し、柔軟なセキュリティポリシー設定を提供します。OIDC を統合することで、シングルサインオン (SSO) も可能になり、一度のログインで複数のサービスにアクセスできるようになります。

    前提条件

    標準の OIDC プロトコルをサポートする統合認証サービスが必要です。

    背景情報

    ゲートウェイは、内部サービスへの外部アクセスのコントロールポイントとして、内部サービスのセキュリティを確保するために外部リクエストを認証する必要があります。企業は通常、統一された自己管理型の認証システムを構築します。Cloud-native Gateway は、OIDC プロトコルを使用してこのようなシステムに接続できます。これにより、ゲートウェイは接続先のすべての内部サービスに対して統一された認証を提供し、各サービスを個別に認証システムに接続する必要がなくなります。

    OIDC 認証

    OIDC は、OAuth 2.0 プロトコル上の ID レイヤーです。これにより、サードパーティのアプリケーションが ID プロバイダーに接続してユーザー情報を取得し、その情報を安全に受け取ることができます。OIDC は、JSON Web Token (JWT) である ID トークンで OAuth 2.0 を拡張します。ID トークンは、基本的なユーザー ID 情報を自己完結型で改ざん防止の形式でカプセル化し、サードパーティのアプリケーションに安全に送信され、簡単に検証できます。

    OIDC では、以下のロールが定義されています。

    • クライアント：ユーザーに直接サービスを提供するアプリケーション。

    • 認可サーバー：認証のために ID トークンを発行する OpenID プロバイダーです。

    • ビジネスサーバー：保護されたリソースやサービスをホストするサーバー。

    • ユーザー：アクセスを許可するリソースオーナー。

    ワークフローは以下のとおりです。

    1. クライアントは認可サーバーに認証リクエストを送信します。

    2. ユーザーは認証ページで認可を確認します。通常、ユーザー名とパスワードでログインします。

    3. 認可サーバーはリクエストを検証し、クライアントに認可コードを返します。

    4. ユーザーはクライアントのコールバックエンドポイントにリダイレクトされ、そこで認可コードが受信されます。

    5. クライアントは、認可コード、クライアント ID、クライアントシークレットを送信して、認可サーバーにトークンをリクエストします。

    6. 認可サーバーはリクエストを検証し、ID トークンを返します。

    7. 認証が成功すると、クライアントは ID トークンを受信し、認証後のリクエストを続行できます。

    8. クライアントは ID トークンを含めて、ビジネスサーバーにリクエストを送信します。

    9. ビジネスサーバーは ID トークンを検証し、レスポンスを返します。

    Cloud-native Gateway による OIDC 認証フロー

    標準の OIDC フローでは、ユーザーサービスや注文サービスなど、複数のビジネスサービスがある場合、各サービスは独自の認証ロジックを実装する必要があります。これには、リクエストの検証や認可サーバーとの統合が含まれます。Cloud-native Gateway の OIDC 認証機能を使用することで、この認証ロジックをゲートウェイレベルで一元化できます。

    ワークフローは以下のとおりです。

    1. クライアントはゲートウェイに認証リクエストを送信します。

    2. ゲートウェイは認可サーバーに認証リクエストを送信します。

    3. 認可サーバーはゲートウェイにコードを返します。

    4. ゲートウェイはクライアントにコードを返します。

    5. クライアントはコードを含むコールバックリクエストをゲートウェイに送信します。

    6. ゲートウェイは認可サーバーとコードをトークンに交換します。

    7. 認可サーバーはゲートウェイに ID トークンを返します。

    8. ゲートウェイはクライアントに認証成功のレスポンスを返し、Cookie を設定します。

    9. クライアントは Cookie を含めてビジネスリクエストを開始し、ゲートウェイはトークンを検証します。

    10. ゲートウェイは ID トークンを含めてビジネスリクエストをビジネスサービスに転送します。

    11. ビジネスサーバーのレスポンスはゲートウェイ経由でクライアントに返されます。

    プロセス全体を通じて、Cloud-native Gateway はリクエストを検証します。リクエストが無効な場合、ゲートウェイはユーザーをログインページにリダイレクトし、認可サーバーとの認証プロセスを中継します。このプロセスは、バックエンドのビジネスサービスに対して透過的です。

    認証ルールの作成

    1. MSE コンソール にログオンします。

    2. 左側のナビゲーションウィンドウで、Cloud-Native Gateway > ゲートウェイリスト を選択します。 上部のナビゲーションバーで、リージョンを選択します。

    3. ゲートウェイリスト ページで、ゲートウェイの名前をクリックします。

    4. 左側のナビゲーションウィンドウで、Security Management > Global Authentication を選択します。

    5. ページの左上隅にある Create Authentication をクリックし、ゲートウェイ認証パラメーターを設定してから OK をクリックします。

      次の表に、Cloud-native Gateway の OIDC 認証パラメーターを示します。

      パラメーター

      説明

      [Authentication Name]

      認証ルールのカスタム名。

      [Authentication Type]

      [OIDC] を選択します。

      Issuer

      認可サーバーの発行者 URI。

      [Redirect URL]

      認可が成功した後にユーザーがリダイレクトされる URL。この URL は、OIDC ID プロバイダーに登録されている URL と一致する必要があります。

      重要

      URL は http(s)://yourdomain/path の形式である必要があります。 パスは /oauth2/callback である必要があります。

      Client ID

      ID プロバイダーに登録されているアプリケーションのクライアント ID。

      Client secret

      ID プロバイダーに登録されているアプリケーションのクライアントシークレット。

      Cookie domain

      Cookie のドメイン。認証が成功すると、Cookie は指定されたドメインに送信され、ログイン状態が維持されます。たとえば、Cookie-domain=a.example.com と設定すると、Cookie は a.example.com ドメインに送信されます。Cookie-domain=.example.com と設定すると、Cookie は example.com のすべてのサブドメインに送信されます。

      Scope

      リクエストする認可スコープを指定します。複数のスコープをセミコロン (;) で区切ります。

      [Grant]

      認可モード。サポートされているモードは Whitelist と Blacklist です。

      • ホワイトリスト：ホワイトリスト内のホストとパスに一致するリクエストは認証をバイパスします。それ以外のすべてのリクエストには認証が必要です。

      • ブラックリスト：ブラックリスト内のホストとパスに一致するリクエストには認証が必要です。それ以外のすべてのリクエストは直接アクセスできます。

      [+ Rule condition] をクリックして、リクエストドメインとパスを設定します。

      • [Domain Name]：リクエストされたドメイン名またはホスト。

      • [Path]：リクエストされた API パス。

    認証ルートの作成

    認証ルールを作成した後、関連するルートを作成する必要があります。詳細については、「ルートの作成」をご参照ください。

    ルートパラメーターを次のように設定します。

    • [Domain Name]：認証ルールで設定した Redirect URL のドメインを選択します。ドメインが設定されていない場合は、* を選択できます。

      重要

      HTTPS を使用する場合は、ドメインを設定して関連付ける必要があります。

    • [Path]：Prefix Match を選択し、/oauth2 を入力します。

    • [Destination Service]：oauth2-proxy を選択します。

    認証詳細の表示

    1. MSE コンソール にログオンします。

    2. 左側のナビゲーションウィンドウで、Cloud-Native Gateway > ゲートウェイリスト を選択します。 上部のナビゲーションバーで、リージョンを選択します。

    3. ゲートウェイリスト ページで、ゲートウェイの名前をクリックします。

    4. 左側のナビゲーションウィンドウで、Security Management > Global Authentication を選択します。

    5. Global Authentication ページで、認証ルールの名前をクリックするか、Actions 列の 詳細 をクリックして、現在の Authentication Configuration を表示し、Authorization Information を管理します。

      認証設定の詳細ページは 3 つのセクションで構成されています。[Basic Information] セクションには名前とソースが表示されます。[Authentication Configuration] セクションには、[Issuer]、[Redirect URL]、[Client ID]、[Client secret]、[Cookie domain]、[Scope] などのフィールドが表示されます。[Authorization Information] セクションには、「ホワイトリストモード」などの認可モードが表示されます。[Create authorization information] をクリックして、リクエストドメインとリクエストパスのマッチングルールを追加できます。複数のルール条件は OR 条件で評価されます。

    Authorization Information セクションで、Add Authorization Information をクリックします。表示されたダイアログボックスで、Request Domain Name と Request Path を入力し、Match Mode を選択してから OK をクリックして、新しい認可ルールを追加します。

    結果の確認

    Global Authentication ページに戻ります。リストに新しい認証ルールが表示されていれば、正常に作成されています。

    関連操作

    認証ルールを管理するために、次の操作も実行できます：

    • 認証ルールの有効化： Global Authentication ページで、対象のルールを見つけ、Actions 列の 有効化 をクリックします。これにより、ルールがアクティブになります。

    • 認証ルールの無効化： Global Authentication ページで、対象のルールを見つけ、Actions 列の Close をクリックします。これにより、ルールが非アクティブになります。

    • 認証ルールの編集： Global Authentication ページで、対象のルールを見つけ、Actions 列の Edit をクリックして、その設定を変更します。

    • 認証ルールの削除： Global Authentication ページで、対象のルールを見つけ、Actions 列の Delete をクリックして、ルールを完全に削除します。

    説明

    認証ルールを削除する前に、まず無効化する必要があります。

    関連トピック

    他の認証メカニズムについては、「Global Authentication」をご参照ください。