APIアクセス管理

APIアクセス管理を使用すると、Oktaでカスタム認可サーバーを構築できます。これを使用して独自のAPIエンドポイントを保護したり、Oktaの組織認可サーバーを使用したりできます。使用可能な認可サーバーのタイプを参照してください。

認可サーバーは、「ステージング」や「本番」などのセキュリティー境界を定義します。各認可サーバー内で、独自のOAuthスコープ、クレームおよびアクセス・ポリシーを定義できます。これにより、アプリとAPIを中央認可ポイントに固定し、属性変換用のUniversal Directory、エンド・ユーザー向けのアダプティブMFA、分析、システム・ログなど、Oktaの豊富なID機能を活用して、APIコミュニティーに拡張することができます。

中核となる認可サーバーは、単なるOAuth 2.0トークン・ミンティング・エンジンです。各認可サーバーには、セキュリティ・ドメイン間の適切な境界を維持するために 、一意の発行者URI とトークン用の独自の署名キーがあります。認可サーバーは、OpenID Connectプロバイダーとしても機能します。つまり、認可サーバーのエンドポイントから、アクセス・トークンに加えてIDトークンも要求することができます。

Oktaの組織認可サーバーまたはカスタム認可サーバーのどちらを使用する必要があるかは、どのようにして確認しますか？

  • Okta以外のリソースを保護する必要があります。
  • ユーザーが従業員、パートナー、エンド・ユーザー、または他の同様の専門分野かどうかに応じて、異なる認可ポリシーが必要です。
情報

注

従業員、パートナー、ユーザーがすべてシングル・サインオンに同じ認証ポリシーを使用できる場合は、組み込みの組織認可サーバーを試してください。

クライアントとOkta間の認証を管理するには

  • クライアント・アプリのスコープとクレームを特定し、Oktaに登録します。
  • 1つ以上の認可サーバーを作成し、アプリで想定されるスコープとクレームを一致させるよう定義します。

どのタスクを先に実行してもかまいませんが、クライアント・アプリはスコープ名を認識し、認可サーバーで定義されたクレームを想定している必要があります。

認可サーバーを作成して構成するには、次の手順に従います。

  1. ダッシュボードから[セキュリティー] > [API]を選択し、[認可サーバー]タブを選択します。次に、[認可サーバーを追加]をクリックし、次の編集可能な情報を入力します。発行者、メタデータURI、最終ローテーションは編集できません。
    • [名前]
    • [オーディエンス] – アクセス・トークンを消費するOAuthリソースのURI。この値は、アクセス・トークンのデフォルトのオーディエンスとして使用されます。
    • [説明]
    • [発行者] – カスタムURLドメインを有効にして定義した場合、[発行者]フィールドはデフォルトでカスタムURLになり、カスタムURL（https://id.example.com）の形式で表示されます。フィールドのドロップダウン矢印を使用して、組織のURLを選択します。

      • または、[動的]を選択して、要求ドメインに応じて組織ドメインまたはカスタム・ドメインのいずれかを使用することもできます。

      これは早期アクセス機能です。有効にする場合は、Oktaサポートにお問い合わせください。

    • [署名キーのローテーション] – 自動または手動。（署名キーのリストを自動的に更新するために認可サーバーにポーリングできないクライアントに対して使用できるのは手動のみです。手動を使用する場合、Oktaは3か月ごとにキーをローテーションすることをお勧めします。）

完了すると、認可サーバーの[設定]タブに入力した情報が表示され、編集できるようになります。

認可サーバーの追加

スコープは、APIエンドポイントで実行できる高レベルの操作を表します。これらはアプリケーションにコード化され、認可サーバーから要求されます。アクセス・ポリシーはどのアプリケーションを許可するか、どのアプリケーションを拒否するかを決定します。

提供されている予約済みスコープに加えてスコープが必要な場合は、ここで作成してください。

  1. 表示する認可サーバーの名前を選択し、[スコープ]を選択します。

  2. [スコープ] > [スコープを追加]を選択します。
  3. 名前と説明を入力します。
  4. このスコープに対するユーザーの同意が必要な場合は、[ユーザーの同意]をオンにします。
  5. 任意：[ユーザーの同意]をオンにした場合は、[サービスがこのスコープを要求するのをブロックする]チェック・ボックスをオフにします。

    チェックを外すと、ユーザーがアプリケーションと対話するときに同意が必要になりますが、スコープがサービス・アプリケーションから認可サーバーに直接要求される場合は同意は必要ありません。詳細については、柔軟な同意を参照してください。

  1. 認可リクエストでスコープを指定していないアプリにOktaが認可リクエストを付与できるようにするには、[デフォルト・スコープ]を選択します。 クライアントが認可要求でスコープ・パラメーターを省略した場合、Oktaはアクセス・ポリシー・ルールで許可されているすべてのデフォルト・スコープをアクセス・トークンで返します。

  2. [保存]をクリックします。

スコープの表示

これらのスコープは、[クレーム]ダイアログによって参照されます。

情報

注

OAuth 2.0とOpenID Connectフローのユーザーの同意機能を使用するアプリを作成する場合は、以下に示すように[ユーザーの同意]を[はい]に設定します。

トークンには、件名または別の件名に関する記述である クレーム が含まれています（名前、ロール、メール・アドレスなど）。

IDトークン・クレームは動的です。デフォルトでは、認可サーバーは、アクセス・トークンまたは認証コードで要求された場合、IDトークン・クレームをIDトークンに含めません。このデフォルトを使用するには、[トークン・タイプに含める]の[要求されたとき]を選択します。

IDトークンに常にIDトークン・クレームを含めるように認可サーバーを強制するには、[トークン・タイプに含める]の[常に]を選択します。

情報

注

クレームが含まれていない場合、クライアントはアクセス・トークンを使用してUserInfoエンドポイントからクレームを取得する必要があります。

OpenID ConnectのIDトークン・クレーム、またはOAuth 2.0のアクセス・トークンを作成します。

  1. 表示する認可サーバーの名前を選択し、[クレーム]を選択します。Oktaはデフォルトの件名クレームを提供します。マッピングを編集するか、独自のクレームを作成できます。

  2. [クレームを追加]を選択し、必要な情報を入力します。

    • [名前]
    • [トークン・タイプに含める]：最初のドロップダウン・ボックスでトークン・タイプを選択します。[アクセス・トークン]（OAuth 2.0）または[IDトークン]（OpenID Connect）を選択します。2番目のドロップダウン・ボックスで、[常に]または[Userinfo/id_token要求]を選択します。
    • [値タイプ]：クレームをグループ・フィルターで定義するか、Okta式言語で記述された式で定義するかを選択します。
      • [マッピング]：このオプションは、前のフィールドで[式]を選択した場合に表示されます。ここでOkta式言語を使用してマッピングを追加します（例：appuser.username）。式が予期した結果を返すことを必ず確認してください。式はここでは検証されません。
      • [フィルター]：このオプションは、前のフィールドで[グループ]を選択した場合に表示されます。グループ・フィルターを追加するために使用します。空白のままにすると、すべてのユーザーがこのクレームに指定されます。
    • [クレームを無効化]：テストまたはデバッグのためにクレームを一時的に無効にするには、このオプションをオンにします。
    • [含める]：クレームが任意のスコープに対して有効かどうかを指定するか、クレームが有効なスコープを選択します。

[クレーム]リストでは、次のことができます。

  • クレームをタイプで並べ替えます。

  • 作成したクレームを削除するか、テストまたはデバッグの目的でクレームを無効にします。

  1. 認可サーバーの名前を選択します。
  2. [アクセス・ポリシー] > [新しいアクセス・ポリシーを追加]を選択します。
  3. 必要な情報を入力します。
    • [名前]
    • [説明]
    • [すべてのクライアント]に割り当てるか、[次のクライアント：]を選択して、このアクセス・ポリシーによってカバーされたクライアントの名前を入力します。

[アクセス・ポリシー]リストでは、次のことができます。

  • テストまたはデバッグの目的で、アクセス・ポリシーをアクティブまたは非アクティブに設定します。
  • ポリシーを並べ替えて、ポリシーの評価順序を変更します。

    • アクセス・ポリシー・リスト

ポリシーはポリシーのルールと同様に、優先度順に評価されます。クライアント要求に一致する最初のポリシーとルールが適用され、それ以降のルールまたはポリシー処理は行われません。

ルールは、クライアント、ユーザー、カスタム・スコープのマッピングを制御します。たとえば、ユーザーがクライアントに割り当てられている場合にカスタム・スコープScope1が有効になるように、アクセス・ポリシーのルールを指定できます。

  1. 認可サーバーの名前を選択し、[アクセス・ポリシー]を選択します。
  2. アクセス・ポリシーの名前を選択し、[ルールを追加]を選択します。
  3. 必要な情報を入力します。
    • [ルール名]
    • [IF：付与タイプ] – クライアントが自身の代わりに動作するか、ユーザーの代わりに動作するかを選択します。両方を選択できます。クライアントがユーザーの代わりに機能している場合は、いずれかまたはすべての方法を選択します。
    • [AND：ユーザー] – このオプションは、上記の[ユーザーの代わりに機能するクライアント]をオンにした場合にのみ表示されます。[アプリに割り当てられているユーザー]を選択するか、さらにユーザーを定義します。
    • [AND：要求されるスコープ] – ユーザーがいずれかの条件を満たした場合に付与されるスコープ（任意のスコープ、または指定したリスト）を選択します。
    • [THEN：このインライン・フックを使用] – 該当する場合は、インライン・フックを選択します。インライン・フックを参照してください。
    • [AND：アクセス・トークンのライフタイム] – アクセス・トークンの有効期限が切れるまでの時間を選択します。
    • [AND：更新トークンのライフタイム] – 更新トークンの有効期限が切れるまでの時間を選択します。

      [更新トークンのライフタイム]で、指定されたライフタイムを検証して続行するためにトークンを使用する必要がある期間を入力します。

      情報

      注

      有効期限は、アクセス・トークンのライフタイムと更新トークンのライフタイムの範囲内である必要があります。最長有効期間は5年です。有効期限内に使用されないトークンは、ライフタイムが無制限に設定されていても期限切れになります。

  4. [ルールを作成]を選択してルールを保存します。

    ルール・リスト

アクセス・ポリシーの[ルール]リストで、以下を実行できます。

  • テストまたはデバッグのためにルールを非アクティブに設定します。

  • デフォルト・ポリシーのデフォルト・ルールを除き、ルールを並べ替えます。ルールは優先順位で評価されるため、クライアント要求に一致する最初のポリシーの最初のルールが適用され、それ以上の処理は行われません。

    情報

    注

    サービス・アプリケーション（クライアント認証情報フロー）にはユーザーがいません。このフローを使用する場合は、条件[ユーザーなし]を指定するルールが1つ以上あることを確認してください。

  • 情報アイコンを選択するかルール名をクリックすると、以下に示すように、ルールが適用されるユーザーとグループ、およびそれらのユーザーとグループに付与されているスコープが表示されます。

認可サーバー、スコープとクレーム、クライアント、ユーザーの各組み合わせについて、API呼び出しを発行し、IDトークンまたはアクセス・トークンの内容が期待どおりであることを確認します。

OpenID Connect IDまたはOAuth 2.0アクセス・トークンのトークン・プレビュー

OpenID Connect IDトークンまたはOauth 2.0アクセス・トークンを使用するようにアプリケーションまたは統合を構成する場合、多くの試行錯誤が必要になる可能性があります。Oktaでは、以下に示すように、より簡単に構成設定を選択し、結果のトークンを[認可サーバー]ページの[トークンのプレビュー]タブに表示できます。

左側に値を追加して、右側のトークンにどのように影響するかを確認します。[ユーザー]を除くすべてのフィールドは選択ボックスです。[ユーザー]の場合、最初の数文字を入力するとユーザー名の選択肢が表示されます。

値の異なる組み合わせを試して、結果のトークン（またはエラー・メッセージ）を確認できます。正しい組み合わせが得られたら、認可サーバーとその他のコンポーネントを簡単に構成できます。

認可サーバーを削除するには、認可サーバー名の右にある[アクション]ボタンをクリックし、[削除]をクリックします。



検索フィールドを使用して、認可サーバーまたはリソースURIの正確な名前で検索します。

手動でキーをローテーションするように認可サーバーを設定できます。キーはデフォルトで自動的にローテーションされます。

重要： 自動キー・ローテーションは手動キー・ローテーションよりも安全です。自動キー・ローテーションが使用できない場合にのみ、手動キー・ローテーションを使用します。

認可サーバーの構成を変更するには：

  1. Okta組織にログインします。
  2. 管理ダッシュボードから[セキュリティー] > [API]に移動します。
  3. 編集のために認可サーバーを開きます。
  4. [署名キーのローテーション]の値を[手動]に変更して保存します。
  5. 認可サーバーの[設定]タブで、[署名キーをローテーションする]ボタンをクリックして、キーを手動でローテーションします。[署名キーのローテーション]が[自動]に設定されている場合、このボタンは表示されません。