OIDCアプリ統合を作成する

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

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

開始する前に

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

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

    • OIDCアプリケーションにリダイレクトしてサインインリクエストを開始します。この仕様は、OpenID Connectの第4項に準拠しています。エンドユーザーがOktaタイルをクリックすると、クライアントアプリケーションのinitialize_login_uriにリダイレクトされます。クライアントアプリケーションは認可リクエストを行い、エンドユーザーをOktaにリダイレクトします。
    • OIDCアプリケーションにIDトークンを直接送信します。これは上記よりも簡素化されたフローであり、OktaがIDトークンを作成し、登録済みの対象アプリケーションリダイレクトURIのうち最初のURIに直接送信します。このフローは、SAMLアプリのサインイン・リクエストの場合と同じです。また、付与するOIDCスコープを構成できます。このフローではform_post応答モードが使用されます。このリクエストは一方向で行われるため、リクエスト内に状態パラメーターがありません。
  • リダイレクトUniform Resource Identifier（URI）のエンドポイントが機能していることを確認します。リダイレクトURIとは、Oktaが認証レスポンスとIDトークンを送信する宛先です。

  • アプリ統合でのインライン指示の問題を回避するには、ブラウザーの設定を開き、常にクッキーを使用できるサイトのリストにOktaを追加します。「サードパーティクッキーを許可する」を参照してください。

コンテキスト

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

「承諾」とは、スコープで保護されたリソースにアプリケーションがアクセスすることを、ユーザーが明示的に許可することです。OAuth 2.0またはOpenID Connectの認証フローでは、統合時に特定のリソースがアクセスされることへの同意をユーザーに求めることができます。あるいは、統合プロセスにユーザーの同意を設定することも可能です。

同意の付与は、トークンの付与とは異なるものです。同意の有効性は、トークンの付与よりも継続します。また、さまざまなスコープが設定された複数のトークンが存在する場合もありますが、それらのスコープは一度の同意に基づいています。

新規のアクセストークンが必要な場合、アプリケーションは、ユーザーが特定のスコープに同意済みであれば、同意を求める必要はありません。承諾は、ユーザーが手動で取り消すか、ユーザー、統合サーバー、認可サーバー、またはスコープが非アクティブ化されるか削除されるまで有効です。ユーザーの同意の機能を使用するには、orgの［API Access Management（APIアクセス管理）］機能が有効になっている必要があります。

タスク1：ウィザードの起動

  1. Okta Admin Consoleで、［Applications（アプリケーション）］>［Applications（アプリケーション）］に移動します。
  2. ［Create App Integration（アプリ統合の作成）］をクリックします。
  3. OIDCアプリの統合を作成するには、［Sign-in method（サインイン方法）］として［OIDC - OpenID Connect］を選択します。
  4. Oktaと統合するアプリケーションのタイプを選択します。［Web Application（ウェブアプリケーション）］、［Single-Page Application（シングルページアプリケーション）］、［Native Application（ネイティブアプリケーション）］のいずれかを選択します。
  5. ［Next（次へ）］をクリックします。

タスク2：初期設定の構成

OIDCのApp Integration Wizardには、次の3つのセクションがあります。

  1. ［General Settings（一般設定）］：
    • ［App integration name（アプリ統合名）］：アプリ統合の名前を指定します。

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

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

    • 任意。［Logo（ロゴ）］：Okta orgのアプリの統合に使用するロゴを追加します。ロゴのファイルは .png、.jpg、.gif形式のいずれかで、1MB未満である必要があります。背景が透明で横向きのPNG画像を使用すると、最適な効果を得られます。アップスケールを防ぐために、420 x 120ピクセル以上の解像度を使用してください。
    • ［Grant type（付与タイプ）］：さまざまな付与タイプ・オプションから選択します。アプリ統合に使用できる付与タイプは、選択したプラットフォームによって異なります。「OAuth 2.0とOpenID Connectの概要」を参照してください。
    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：サインインリダイレクトURIとは、Oktaがサインインリクエストの認証レスポンスとIDトークンを送信する宛先です。URIは絶対URIでなければなりません。

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

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

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

    • 任意。［Sign-out redirect URIs（サインアウトリダイレクトURI）］：アプリケーションが、Oktaにユーザーセッションのクローズを要求すると、Oktaは、ユーザーをこのURIにリダイレクトします。URIは絶対URIでなければなりません。複数のURIを指定できます。サブドメインへのワイルドカードの使用は、サインアウトリダイレクトURIでは現在サポートされていません。

  2. ［Trusted Origins（信頼済みオリジン）］（Webおよびネイティブアプリ統合用）：

    • 任意。［Base URIs（ベースURI）］：Okta APIへのクロスオリジンリクエストを許可するベースURIを指定します。これらのURIは、Okta orgの［Trusted Origins（信頼済みオリジン）］に追加されます。これらを管理するには、［Security（セキュリティ）］>［API］に移動して、［Trusted Origins（信頼済みオリジン）］タブを選択します。「オリジン間リソース共有（CORS）の概要」をご覧ください。

  3. ［Assignments（割り当て）］：

    • ［Controlled access（制御対象アクセス）］：デフォルトのアクセスオプションによって、Okta orgの全ユーザーに、この新しいアプリ統合へのアクセス権が割り当てられ、付与されます。［Limit access to selected groups（選択したグループへのアクセスを制限）］を選択してから、orgに所属する特定のグループの名前を入力できます。または、［Skip group assignment for now（今はグループの割り当てをスキップ）］を選択して、グループを割り当てずにアプリを作成することもできます。

  4. ［Save（保存）］をクリックします。クリックするとアプリの統合が作成され、追加オプションを構成するための設定ページが開きます。

タスク3：OIDC設定の構成

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

ウェブアプリ

  • ［Client Credentials（クライアントの認証情報）］セクションには、認証フローに必要な重要な情報が含まれています。

    • ［Client ID（クライアントID）］：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。

      ［Client ID（クライアントID）］：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。

    • ［Client authentication（クライアント認証）］：クライアント認証に使用する方法を選択します。

      • ［Client secrets（クライアントシークレット）］：このオプションを選択すると、クライアントが使用するシークレットを生成できるパネルが表示されます。この値は、Oktaとアプリの統合にのみ認識されます。［Save（保存）］をクリックして、クライアントシークレットを生成します。クライアントシークレットを表示またはコピーできます。2番目のクライアントシークレットがある場合は、ステータスを変更してアクティブなシークレットを選択できます。「2つ目のクライアントシークレットを作成してクライアントシークレットをローテーションする」を参照してください。

      • ［Public key / Private key（公開鍵/秘密鍵）］：このオプションを選択すると、クライアント接続で使用する公開鍵と秘密鍵のペアを生成または追加できるパネルが表示されます。「OIDCアプリのシークレットとキーを管理する」を参照してください。
    • ［Proof Key for Code Exchange (PKCE)］：クライアントリクエストを確認するためにPKCEコードチャレンジが必要かどうかを示します。これは［Client secrets（クライアントシークレット）］と［Public key / Private key（公開鍵/秘密鍵）］の両方の認証方法のオプションです。

    • ［Save（保存）］をクリックして、［Client Credentials（クライアントの認証情報）］の変更を確定します。クライアントシークレットと公開鍵/秘密鍵を切り替える場合の既存のシークレットまたはキーの削除については、「クライアント認証方法を変更する」を参照してください。

  • ［General Settings（一般設定）］セクションでは、アプリの統合の次の設定を構成できます：

    • ［App integration name（アプリの統合名）］の初期名を必要に応じて変更します。

    • 付与タイプをさまざまな［Grant type（付与タイプ）］オプションから選択します。

      • ［Refresh Token（トークンを更新）］付与タイプを選択した場合、使用後に毎回トークンをローテーションするか、永続的トークンを使用するかを選択できます。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。

    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、［Require consent（同意が必要）］ボックスをオンにします。「API access management（APIアクセス管理）」の「Create Scopes（スコープの作成）」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。［Require consent（同意が必要）］は、orgでOkta API Access Managementが有効になっている場合にのみ表示されることに注意してください。

    • OktaがOAuth応答を送信する［Sign-in redirect URIs（サインインリダイレクトURI）］を1つ以上入力します。

    • 証明書利用者（Relying Party（RP））からのログアウトが完了し、エンドユーザーセッションが終了した後に、Oktaがブラウザーをリダイレクトする［Sign-out redirect URIs（サインアウトリダイレクトURI）］を1つ以上選択します。

    • ［Login initiated by（ログイン開始元）］設定を選択して、アプリケーションがサインインプロセスを直接開始するか、アプリケーションまたはOktaがサインインリクエストを開始するかを指定します。

      • ［App Only（アプリのみ）］を選択した場合、アプリケーションはバックグラウンドで開始され、Oktaタイルは表示されません。

      • ［Either Okta or App（Oktaまたはアプリのいずれか）］を選択した場合、統合でOktaタイルが表示されます。

        • 適切な［Application visibility（アプリケーションの可視性）］オプションを選択します。

        • 適切な［Login flow（ログインフロー）］オプションを選択します。［Send ID Token directly to app (Okta Simplified)（IDトークンをアプリへ直接送信（Okta簡略化））］を選択した場合、フローのOIDCスコープも選択できます。

        • 暗黙的なフローを使用している場合、［App Embed Link（アプリの埋め込みリンク）］セクションが設定ページの下部に表示され、Okta外部からOIDCクライアントへのサインインに使用できるURLが示されます。

    • サインインリクエストの開始に使用する［Initiate login URI（ログイン開始のURI）］を入力または変更します。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが認可要求を送信します。

    • ［Save（保存）］をクリックして、［General Settings（一般設定）］の変更を確定します。

シングルページアプリ

  • ［Client Credentials（クライアントの認証情報）］セクションには、認証フローに必要な重要な情報が含まれています。

    • ［Client ID（クライアントID）］：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。

    • ［Client authentication（クライアント認証）］：クライアント認証に使用する方法を選択します。

      • ［None（なし）］：SPA統合のデフォルト。このオプションでは、追加認証のために［Proof Key for Code Exchange（PKCE）］が必要です。PKCEにより、アクセストークンをリクエストしたクライアントのみがトークンを取得できます。

  • ［General Settings（一般設定）］セクションでは、アプリの統合の次の設定を構成できます：

    • ［App integration name（アプリの統合名）］の初期名を必要に応じて変更します。

    • 付与タイプをさまざまな［Grant type（付与タイプ）］オプションから選択します。

      • ［Refresh Token（トークンを更新）］付与タイプを選択した場合、使用後に毎回トークンをローテーションするか、永続的トークンを使用するかを選択できます。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。

    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、［Require consent（同意が必要）］ボックスをオンにします。「API access management（APIアクセス管理）」の「Create Scopes（スコープの作成）」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。［Require consent（同意が必要）］は、orgでOkta API Access Managementが有効になっている場合にのみ表示されることに注意してください。

    • OktaがOAuth応答を送信する［Sign-in redirect URIs（サインインリダイレクトURI）］を1つ以上入力します。

    • 証明書利用者（Relying Party（RP））からのログアウトが完了し、エンドユーザーセッションが終了した後に、Oktaがブラウザーをリダイレクトする［Sign-out redirect URIs（サインアウトリダイレクトURI）］を1つ以上選択します。

    • ［Login initiated by（ログイン開始元）］設定を選択して、アプリケーションがサインインプロセスを直接開始するか、アプリケーションまたはOktaがサインインリクエストを開始するかを指定します。

      • ［App Only（アプリのみ）］を選択した場合、アプリケーションはバックグラウンドで開始され、Oktaタイルは表示されません。

      • ［Either Okta or App（Oktaまたはアプリのいずれか）］を選択した場合、統合でOktaタイルが表示されます。

        • 適切な［Application visibility（アプリケーションの可視性）］オプションを選択します。

        • 適切な［Login flow（ログインフロー）］オプションを選択します。［Send ID Token directly to app (Okta Simplified)（IDトークンをアプリへ直接送信（Okta簡略化））］を選択した場合、フローのOIDCスコープも選択できます。

        • 暗黙的なフローを使用している場合、［App Embed Link（アプリの埋め込みリンク）］セクションが設定ページの下部に表示され、Okta外部からOIDCクライアントへのサインインに使用できるURLが示されます。

    • サインインリクエストの開始に使用する［Initiate login URI（ログイン開始のURI）］を入力または変更します。

    • ［Email Verification Experience（メール検証エクスペリエンス）］：この設定により、メールマジックリンクをオーセンティケーターとして使用する際のエンドユーザーエクスペリエンスをカスタマイズできます。エンドユーザーがワンタイムマジックリンクをクリックして、組み込みのサインインウィジェットを使用するorgでIDを確認すると、Oktaはトークンを検証し、ブラウザーリクエストをこのURIの場所にリダイレクトします。このURIの値を設定して、エンドユーザーを特定のOIDCアプリ統合、orgのOkta End-User Dashboard、または任意のカスタムWebサイトに送信できます。このURIが存在しない場合、Oktaはリダイレクトサインインフローを使用し、エンドユーザーをOkta End-User Dashboardに送信します。

    • ［Save（保存）］をクリックして、［General Settings（一般設定）］の変更を確定します。

ネイティブアプリ

  • ［Client Credentials（クライアントの認証情報）］セクションには、認証フローに必要な重要な情報が含まれています。

    • ［Client ID（クライアントID）］：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。

    • ［Client authentication（クライアント認証）］：クライアント認証に使用する方法を選択します。

      • ［None（なし）］：ネイティブアプリケーションに推奨。

        このオプションでは、追加認証のために［Proof Key for Code Exchange（PKCE）］が必要です。PKCEにより、アクセストークンをリクエストしたクライアントのみがトークンを取得できます。

      • ［Client secrets（クライアントシークレット）］：このオプションを選択すると、クライアントが使用するシークレットを生成できるパネルが表示されます。この値は、Oktaとアプリの統合にのみ認識されます。［Save（保存）］をクリックして、クライアントシークレットを生成します。クライアントシークレットを表示またはコピーできます。2番目のクライアントシークレットがある場合は、ステータスを変更してアクティブなシークレットを選択できます。「2つ目のクライアントシークレットを作成してクライアントシークレットをローテーションする」を参照してください。

      • ［Public key / Private key（公開鍵/秘密鍵）］：このオプションを選択すると、クライアント接続で使用する公開鍵と秘密鍵のペアを生成または追加できるパネルが表示されます。「OIDCアプリのシークレットとキーを管理する」を参照してください。
    • ［Proof Key for Code Exchange (PKCE)］：クライアントリクエストを確認するためにPKCEコードチャレンジが必要かどうかを示します。認証方法として［None（なし）］を選択すると、デフォルトでPKCEチャレンジが必要になります。PKCEコードの確認は、［Client secrets（クライアントシークレット）］と［Public key / Private key（公開鍵/秘密鍵）］の両方の認証方法のオプションです。

    • ［Save（保存）］をクリックして、［Client Credentials（クライアントの認証情報）］の変更を確定します。クライアントシークレットと公開鍵/秘密鍵を切り替える場合の既存のシークレットまたはキーの削除については、「クライアント認証方法を変更する」を参照してください。

  • ［General Settings（一般設定）］セクションでは、次の設定を構成できます：

    • ［App integration name（アプリの統合名）］の初期名を必要に応じて変更します。

    • 付与タイプをさまざまな［Grant type（付与タイプ）］オプションから選択します。

      • ［Refresh Token（トークンを更新）］付与タイプを選択した場合、使用後に毎回トークンをローテーションするか、永続的トークンを使用するかを選択できます。

    • OIDC統合へのユーザーの同意を追加または削除します。統合時に特定のリソースにアクセスすることを承諾するように求めるポップアップ・ウィンドウをユーザーに表示するには、［Require consent（同意が必要）］ボックスをオンにします。「API access management（APIアクセス管理）」の「Create Scopes（スコープの作成）」セクションに記載されているように、カスタム認証でOIDCスコープの同意を設定することもできます。［Require consent（同意が必要）］は、orgでOkta API Access Managementが有効になっている場合にのみ表示されることに注意してください。

    • OktaがOAuth応答を送信する［Sign-in redirect URIs（サインインリダイレクトURI）］を1つ以上入力します。

    • 証明書利用者（Relying Party（RP））からのログアウトが完了し、エンドユーザーセッションが終了した後に、Oktaがブラウザーをリダイレクトする［Sign-out redirect URIs（サインアウトリダイレクトURI）］を1つ以上選択します。

    • サインインリクエストの開始に使用する［Initiate login URI（ログイン開始のURI）］を入力または変更します。

    • ［Save（保存）］をクリックして、［General Settings（一般設定）］の変更を確定します。

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

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

  1. ［Sign On（サインオン）］タブに移動し、［OpenID Connect ID Token（OpenID Connect IDトークン）］セクションまで下方にスクロールします。

  2. ［Groups claim type（グループクレームタイプ）］を選択します。既存グループのクレームを［Filter（フィルター）］することも、［Expression（式）］を選択して、異なるグループのクレームにカスタム・フィルターを作成することもできます。

    ［Groups claim filter（グループ・クレーム・フィルター）］で指定した値と一致するグループが100を超えており、「認証コード」または「PKCE付き認証コード」のどちらの付与タイプも使用していないときに、APIがIDトークンを作成しようとするとエラーが発生します。

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

カスタムURLドメインの使用

カスタムURLドメインを有効にして定義した場合、［Issuer（発行者）］フィールドはデフォルトでカスタムURLになり、カスタムURL（https://id.example.com）の形式で表示されます。フィールドのドロップダウン矢印を使用して、組織のURLを選択します。

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

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

次の手順