AIWを使用してOIDCアプリ統合を作成する

OpenID Connect(OIDC)によるアプリ統合では、OAuth 2.0プロトコル上にIDレイヤーを形成して、エンド・ユーザーのID検証とプロファイル情報の取得を行います。

OpenID Connect Foundationの情報と仕様を詳細に確認するには、「Welcome to OpenID Connect」を参照してください。

開始する前に

  • アプリ統合のプラットフォームを決定します。使用可能なプラットフォームは、ウェブ・アプリケーション、ネイティブ・アプリケーション、シングル・ページ・アプリケーション(SPA)です。
  • 対象のアプリケーションがWebまたはネイティブ・アプリケーションの場合、トークンの更新を使用するかどうかを決定します。
  • 対象のアプリケーションがシングル・ページ・アプリケーション(SPA)の場合、どのような可視性ログイン・フローを使用するかを決定します。Oktaタイルを使用せずに統合がバックグラウンドで行われるように構成したり、サインイン要求を構成して、アプリケーションまたはOktaによって統合を開始するようにしたりできます。

    アプリケーションまたはOktaがサインイン要求を開始する場合のフローとして、次の2つの選択肢を利用できます。

    • OIDCアプリケーションにリダイレクトしてサインイン要求を開始します。 この仕様は、OpenID Connectの第4項 に準拠しています。Oktaタイルをクリックしたエンド・ユーザーは、クライアント・アプリケーションのinitiate_login_uriにリダイレクトされます。これにより、認可要求が行われ、エンド・ユーザーはOktaにリダイレクトされます。
    • OIDCアプリケーションにIDトークンを直接送信します。 これは上記よりも簡素化されたフローであり、OktaがIDトークンを作成し、登録済みの対象アプリケーション・リダイレクトURIのうち最初のURIに直接送信します。このフローは、SAMLアプリのサインイン要求の場合と同じです。また、承諾するOIDCスコープを構成できます。このフローではform_post応答モードが使用されます。この要求は一方向で行われるため、要求内に状態パラメーターがありません。
  • リダイレクトUniform Resource Identifier(URI)のエンドポイントが機能していることを確認します。リダイレクトURI とは、Oktaが認証応答とIDトークンを送信する宛先です。
  • アプリ統合で発生する、インライン指示の問題を回避するには、ブラウザーの設定を開き、常にCookieを使用できるサイトのリストにOktaを追加します。サードパーティーのCookieの許可を参照してください。

コンテキスト

OAuth 2.0とOpenID Connectのフローに対するユーザーの同意

「承諾」とは、スコープで保護されたリソースにアプリケーションがアクセスすることを、ユーザーが明示的に許可することです。OAuth 2.0またはOpenID Connectの認証フローでは、統合時に特定のリソースがアクセスされることへの承諾をユーザーに求めることができます。あるいは、統合プロセスにユーザーの承諾を設定することも可能です。この「承諾」は、トークンの付与とは異なるものです。承諾の有効性は、トークンの付与よりも継続します。また、さまざまなスコープが設定された複数のトークンが存在する場合もありますが、それらのスコープは一度の「承諾」に基づいています。新規のアクセス・トークンが必要な場合、アプリケーションは、ユーザーが特定のスコープに同意済みであれば、承諾を求める必要はありません。承諾は、ユーザーが手動で取り消すか、ユーザー、統合サーバー、認可サーバー、またはスコープが非アクティブ化されるか削除されるまで有効です。ユーザーの同意の機能を使用するには、組織の[APIアクセス管理]機能が有効になっている必要があります。

タスク1:ウィザードを起動する

  1. 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]
  2. [アプリ統合を作成]をクリックします。
  3. OIDCアプリ統合を作成するには、[サインイン方法][OIDC - OpenID Connect]を選択します。
  4. Oktaと統合するアプリケーションのタイプを選択します。[Webアプリケーション][シングル・ページ・アプリケーション]、または[ネイティブ・アプリケーション]のいずれかを選択します。
  5. [次へ]をクリックします。

タスク2:初期設定を構成する

OIDCのアプリ統合ウィザードには、次の3つのセクションがあります。

  1. [一般設定]
    • [アプリ統合名]:アプリ統合の名前を指定します。
      情報

      アプリ統合名には、UTF-8の3バイト文字のみ使用できます。

    • Oktaは、お客様が選択したプラットフォームに基づいて、デフォルト名を自動的にアプリ統合に割り当てます。Okta組織に、そのデフォルト名を持つアプリ統合がすでにある場合、統合名に番号を追加することでそれらを区別します。

    • 任意:[ロゴ]:Okta組織のアプリ統合に使用するロゴを追加します。ロゴ・ファイルはPNG、JPG、またはGIF形式で、サイズが1MB未満のものを選択する必要があります。背景が透明で横向きのPNG画像を使用すると、最適な効果を得られます。アップスケールを防ぐために、420 x 120ピクセル以上の解像度を使用してください。
    • [付与タイプ]:さまざまな付与タイプ・オプションから選択します。アプリ統合に使用できる付与タイプは、選択したプラットフォームによって異なります。「OAuth 2.0とOpenID Connectの概要」を参照してください。
    • [サインイン・リダイレクトURI]サインイン・リダイレクトURI とは、Oktaがサインイン要求の認証応答とIDトークンを送信する宛先です。URIは絶対URIでなければなりません。

      複数のURIを指定できます。OIDCアプリケーションは、使用するredirect_uriを明示的に要求する必要があり、URIはどのような順序でも指定可能です。ただし、OIDCアプリケーションがOktaアプリ統合に登録されていないURIに要求を送信すると、サインオンしようとしたユーザーにエラー・ページが表示されます。

      複数のサブドメインをサポートするようにOIDCクライアントが構成されている場合、1つのリダイレクトURIをワイルドカードで指定できます。[サインイン・リダイレクトURIのワイルドカードを許可する]を選択してください。ワイルドカードの構成ガイドについては、「アプリのAPI」を参照してください。

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

      注意

      サブドメインへのワイルドカードの使用は推奨されません。悪意のあるアクターが、トークンや認証コードを、予期せぬページや攻撃者が制御するページに送信する恐れがあるからです。

    • 任意:[サインアウト・リダイレクトURI]:アプリケーションが、Oktaにユーザー・セッションのクローズを要求すると、Oktaは、ユーザーをこのURIにリダイレクトします。URIは絶対URIでなければなりません。複数のURIを指定できます。
  2. [信頼できるオリジン] (Webおよびネイティブ・アプリ統合用)
    • 任意:[ベースURI]:Okta APIへのクロスオリジン要求を許可するベースURIを指定します。これらのURIは、Okta組織の[信頼できるオリジン]に追加されます。これらを管理するには、[セキュリティー] > [API]に移動して、[信頼できるオリジン]タブを選択します。「クロスオリジン・リソース共有の概要(CORS)」参照してください。
  3. [割り当て]
    • [制御対象アクセス]:デフォルトのアクセス・オプションによって、Okta組織の全ユーザーに、この新しいアプリ統合へのアクセス権が割り当てられ、付与されます。その代わりに、[選択したグループへのアクセスを制限]を選択して組織に所属する特定のグループの名前をフィールドに入力することも、[今回はグループの割り当てを省略する]を選択してグループを割り当てずにアプリを作成することもできます。
  4. [保存]をクリックします。このアクションにより、アプリ統合が作成され、追加のオプションを構成する設定ページが開きます。

タスク3:OIDC設定を構成する

[一般]タブのオプションは、すべてのOIDC統合タイプで同様です。 [編集] をクリックして、表示されたオプションを変更します。

ウェブ・アプリ

  • [クライアントの認証情報]セクションには、アプリ統合の[クライアントID][クライアント・シークレット]の値があります。他の構成作業に必要な場合、これらをコピーする必要があります。必要に応じて、新しいクライアント・シークレットを生成することも可能です。[編集]をクリックして、[新しいクライアント・シークレットを生成]を選択します。
  • [一般設定]セクションでは、アプリ統合にとって重要な各種設定を構成できます 。
    • [アプリ統合名]の初期名を必要に応じて変更します。
    • 付与タイプをさまざまな[付与タイプ]オプションから選択します。
    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、[同意が必要]ボックスをオンにします。APIアクセス管理の「スコープの作成」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。
    • OktaがOAuth応答を送信する[サインイン・リダイレクトURI]を1つ以上入力します。
    • 証明書利用者(Relying Party(RP))からのログアウトが完了し、エンド・ユーザー・セッションが終了した後に、Oktaがブラウザーをリダイレクトする[サインアウト・リダイレクトURI]を1つ以上入力します。
    • [ログイン開始元]を選択して、アプリケーションがサインイン・プロセスを直接開始するか、アプリケーションまたはOktaがサインイン要求を開始するかを指定します。
      • [アプリのみ]を選択した場合、アプリケーションはバックグラウンドで開始され、Oktaタイルは表示されません。
      • [Oktaまたはアプリのいずれか]を選択すると、統合時にOktaタイルが表示されます。
        • 適切な[アプリケーションの可視性]オプションを選択します。
        • 適切な[ログイン・フロー]オプションを選択します。[IDトークンをアプリへ直接送信(Okta簡略化)]を選択した場合、フローのOIDCスコープも選択できます。
        • 暗黙的なフローを使用している場合、[アプリの埋め込みリンク]セクションが設定ページの下部に表示され、Okta外部からOIDCクライアントへのサインインに使用できるURLが示されます。

      openid-configuration APIエンドポイントを使用して、Oktaとのやり取りをプログラムで構成できます。Webアプリケーションのgrant_types_supported暗黙的な値が設定されている場合 、管理者は[ログイン開始元]機能を使用して統合を公開できます。OIDCクライアントとAPIの詳細については、「OpenID ConnectのAPI」を参照してください。

    • サインイン要求の開始に使用する[ログイン開始のURI]を入力または変更します。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが認可要求を送信します。
    • [保存]をクリックして、[一般設定]の変更を確定します。

シングル・ページ・アプリ

  • [クライアントの認証情報]セクションには、アプリ統合用の[クライアントID]があります。また、[クライアント認証]も表示されており、これには、デフォルトでProof Key for Code Exchange(PKCE)が使用されます。このオプションにより、アクセス・トークンを要求したクライアントのみがトークンを取得できます。
  • [一般設定]セクションでは、アプリ統合にとって重要な各種設定を構成できます 。
    • [アプリ統合名]の初期名を必要に応じて変更します。
    • 付与タイプをさまざまな[付与タイプ]オプションから選択します。
      • [トークンを更新]付与タイプを選択した場合、使用後に毎回トークンをローテーションするか、永続的トークンを使用するかを選択できます。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、[同意が必要]ボックスをオンにします。APIアクセス管理の「スコープの作成」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。
    • OktaがOAuth応答を送信する[サインイン・リダイレクトURI]を1つ以上入力します。
    • 証明書利用者(Relying Party(RP))からのログアウトが完了し、エンド・ユーザー・セッションが終了した後に、Oktaがブラウザーをリダイレクトする[サインアウト・リダイレクトURI]を1つ以上入力します。
    • [ログイン開始元]を選択して、アプリケーションがサインイン・プロセスを直接開始するか、アプリケーションまたはOktaがサインイン要求を開始するかを指定します。
      • [アプリのみ]を選択した場合、アプリケーションはバックグラウンドで開始され、Oktaタイルは表示されません。
      • [Oktaまたはアプリのいずれか]を選択すると、統合時にOktaタイルが表示されます。
        • 適切な[アプリケーションの可視性]オプションを選択します。
        • 適切な[ログイン・フロー]オプションを選択します。[IDトークンをアプリへ直接送信(Okta簡略化)]を選択した場合、フローのOIDCスコープも選択できます。
        • 暗黙的なフローを使用している場合、[アプリの埋め込みリンク]セクションが設定ページの下部に表示され、Okta外部からOIDCクライアントへのサインインに使用できるURLが示されます。

      openid-configuration APIエンドポイントを使用して、Oktaとのやり取りをプログラムで構成できます。Webアプリケーションのgrant_types_supported暗黙的な値が設定されている場合 、管理者は[ログイン開始元]機能を使用して統合を公開できます。OIDCクライアントとAPIの詳細については、「OpenID ConnectのAPI」を参照してください。

    • サインイン要求の開始に使用する[ログイン開始のURI]を入力または変更します。
    • [保存]をクリックして、[一般設定]の変更を確定します。

ネイティブ・アプリ

  • [クライアントの認証情報]セクションには、アプリ統合用の[クライアントID]があります。また、[クライアント認証]タイプを選択できます。
    • [PKCEを使用(公開クライアント用)] :ネイティブ・アプリケーションに推奨されます。このオプションでは、コード交換用の証明キー(PKCE)を要求することで、アクセス・トークンを要求したクライアントのみがそのトークンを取得できるようにします。
    • [クライアント認証を使用] :このオプションは分散ネイティブ・アプリケーションには推奨されません。クライアントに埋め込まれたクライアント・シークレットを要求時に送信することで、クライアントのアイデンティティを証明します。
    • [保存]をクリックして、[クライアントの認証情報] の変更を確定します。
  • [一般設定]セクションでは、アプリ統合にとって重要な各種設定を構成できます 。
    • [アプリ統合名]の初期名を必要に応じて変更します。
    • 付与タイプをさまざまな[付与タイプ]オプションから選択します。
      • [トークンを更新]付与タイプを選択した場合、使用後に毎回トークンをローテーションするか、永続的トークンを使用するかを選択できます。
    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、[同意が必要]ボックスをオンにします。APIアクセス管理の「スコープの作成」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。
    • OktaがOAuth応答を送信する[サインイン・リダイレクトURI]を1つ以上入力します。
    • 証明書利用者(Relying Party(RP))からのログアウトが完了し、エンド・ユーザー・セッションが終了した後に、Oktaがブラウザーをリダイレクトする[サインアウト・リダイレクトURI]を1つ以上入力します。
    • サインイン要求の開始に使用する[ログイン開始のURI]を入力または変更します。
    • [保存]をクリックして、[一般設定]の変更を確定します。

タスク4:オプション設定を構成する

グループ・クレーム・フィルターを設定する

  1. [サインオン]タブに移動し、 [OpenID Connect IDトークン]セクションまで下にスクロールします。
  2. [グループのクレーム・タイプ]を選択します。既存グループのクレームを[フィルター]することも、[式]を選択して、異なるグループのクレームにカスタム・フィルターを作成することもできます。[グループのクレーム・フィルター]で指定した値と一致するグループが100を超えているときに、APIがIDトークンを作成しようとするとエラーが発生します。

    シングル・サインオンを行うグループ・クレームの詳細については、「Oktaから返るトークンのカスタマイズ」を参照してください。

次の手順