OpenID Connectアプリ統合を作成する

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

Oktaでは、OIDCプロトコルのすべてのパラメーターをサポートしています。これらのパラメーターを表示するには、「OpenID Connect & OAuth 2.0 API」を参照してください。

開始する前に

  • 「Welcome to OpenID Connect」でOpenID Connect Foundation（OIDF）について学び、完全なプロトコル仕様を確認してください。
  • アプリ統合のプラットフォームを選択します。プラットフォームは、Web、ネイティブ、またはシングルページアプリ（SPA）を選択することができます。
    • 対象のアプリがWebまたはネイティブアプリであれば、トークンの更新を使用するかどうかを決定します。
    • 対象のアプリがシングルページアプリ（SPA）であれば、どのような可視性とサインインフローを使用するかを決定します。サインインフローを（Oktaタイルを使用することなく）バックグラウンドで開始するか、サインインリクエストを始めるのにアプリまたはOktaを有効化することができます。

      アプリまたはOktaがサインインリクエストを開始する場合、フローには次の2つの選択肢があります。

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

  • アプリ統合に手順指示へのリンクが含まれるときは、cookieを常時利用できるサイトのリストにOktaを追加してアクセスに関する問題を回避します。「サードパーティクッキー廃止の影響を軽減する」を参照してください。

ウィザードを起動する

  1. Admin Consoleで［Applications（アプリケーション）］［Applications（アプリケーション）］に移動します。

  2. ［Create App Integration（アプリ統合を作成）］ をクリックします。
  3. ［Sign-in method（サインイン方法）］として［OIDC - OpenID Connect］を選択します。
  4. Oktaと統合するアプリのタイプを選択します。
    • Webアプリケーション
    • シングルページアプリケーション
    • ネイティブアプリケーション
  5. ［Next（次へ）］をクリックします。

一般設定を構成する

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

  1. ［General Settings（一般設定）］：
    • ［App integration name（アプリ統合名）］：アプリ統合の名前を指定します。アプリ統合の名前には、UTF-8の3バイト文字のみ使用できます。

      アプリ統合には、選択したプラットフォームに応じて自動的にデフォルト名が割り当てられます。同じデフォルト名のアプリ統合がすでにOkta orgに存在する場合、統合を区別できるようにデフォルト名に数値が追加されます。

    • ［Application notes for end users（エンドユーザー向けアプリケーションノート）］：アプリに関する注記がOkta End-User Dashboardに表示されるように、フィールドにテキストを入力します。
    • ［Application notes for admins（管理者向けアプリケーションノート）］：管理者向けのアプリに関する注記がOIDCアプリページに表示されるように、フィールドにテキストを入力します。
    • ［Require Demonstrating Proof of Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］：公開/秘密鍵ペアの所有をトークンリクエストで証明するようにクライアントに求めるには、このオプションを選択します。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。DPoPを必須とするときは、［付与タイプ］オプションの［Implicit (hybrid)（暗黙（ハイブリッド））］は選択できません。
    • ［Grant type（付与タイプ）］：使用する付与タイプを選択します。その他の付与タイプを表示するには、［Advanced（詳細設定）］をクリックします。各付与タイプの説明については、「直接認証付与タイプを構成する」を参照してください。アプリ統合に使用できる付与タイプは、選択するプラットフォームによって異なります。「OAuth 2.0とOpenID Connectの概要」を参照してください。
    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：Oktaがサインインリクエストの認証レスポンスとIDトークンを返す送信先です。URIは絶対URIである必要があります。

      複数のURIを指定して、任意の順序に並べ替えることができます。統合に登録されていない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（信頼済みオリジン）］に追加されます。ベースURIを管理するには、［Security（セキュリティ）］［API］に移動して［Trusted Origins（信頼済みオリジン）］タブを選択します。「クロスオリジンリソース共有（CORS）の概要」参照してください。
  3. ［Assignments（割り当て）］：デフォルトのオプションでは、このアプリ統合へのアクセス権がOkta orgの全ユーザーに割り当てられて付与されます。
    • ［Controlled access（アクセス制御）］：
      • ［Limit access to selected groups（選択されたグループにアクセスを制限）］：アクセス権を付与するグループの名前を入力します。
      • ［Skip group assignment for now（今はグループの割り当てをスキップ）］：グループを割り当てることなく、アプリを作成します。
  4. ［Save（保存）］をクリックします。設定ページが表示されます。

OINからアプリ統合を追加すると、Update application（アプリケーションの更新）イベントが生成され、システムログに表示されます。 このイベントは、既存アプリの新規インスタンスの作成を反映しています。

App Integration Wizard（AIW）を使ってアプリを作成すると、Create application（アプリケーションの作成）イベントが生成され、システムログに表示されます。 このイベントは、新規アプリの作成を反映しています。

OIDC設定を構成する

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

Webアプリ

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

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

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

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

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

  • ［Save（保存）］をクリックします。

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

［アプリケーション］セクションで、アプリの詳細を構成します。

  • ［App integration name（アプリ統合名）］：必要に応じて、名前を変更します。
  • ［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］：このオプションを選択すると、トークンリクエストでクライアントに公開鍵と秘密鍵のペアを所有していることの証明が要求されます。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。DPoPを必須とするときは、［付与タイプ］オプションの［Implicit (hybrid)（暗黙（ハイブリッド））］を選択できません。
  • ［Grant type（付与タイプ）］：以下の付与タイプを選択します。
    • ［Client credentials（クライアントの資格情報）］：自分自身の代わりに動作するクライアントには、クライアント資格情報を使用します。
    • ［Authorization code（認可コード）］：ユーザーの代わりに動作するクライアントには、認可コードを使用します。
    • ［Refresh Token（リフレッシュトークン）］：使用するたび、または永続的トークンを使用するたびにトークンをローテーションします。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
    • ［Device Authorization（デバイス認可）］：デバイス認可は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Implicit (hybrid)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。使用するトークンのタイプを選択します。
      • Allow ID token with implicit grant type（暗黙の付与タイプでIDトークンを許可）
      • Allow Access token with implicit grant type（暗黙の付与タイプでアクセストークンを許可）

［ユーザーの同意］セクションで、OIDC統合のユーザー同意を追加または削除します。

  • ［Require consent（同意が必要）］：このオプションを選択すると、統合が特定のリソースにアクセスすることの承認を促すポップアップウィンドウがユーザーに表示されます。「APIアクセススコープを作成する」で説明されているように、OIDCスコープへの同意はカスタム認可にセットアップできます。このチェックボックスは、orgにOkta API Access Managementが有効な場合にのみ表示されます。詳細については、「ユーザーの同意を要求する」を参照してください。
  • ［Terms of Service URI（利用規約のURI）］：同意ポップアップウィンドウに表示する利用規約テキストの保管場所のリンクを貼り付けます。
  • ［Policy URI（ポリシーのURI）］：同意ポップアップ ウィンドウに表示するポリシーテキストの保管場所のリンクを貼り付けます。
  • ［Logo URI（ロゴのURI）］：同意ポップアップ ウィンドウに表示するロゴの保管場所のリンクを貼り付けます。 背景が透明な横長の.png画像を使用すると最適になります。拡大されることがないように、420 x 120ピクセル以上の解像度を使用します。

［ログアウト］セクションで、アプリからサインアウトするためのオプションを構成します。

  • ［ログイン］：アプリのサインインとサインアウトにURIを構成します。
  • ［Sign-in redirect URIs（サインインリダイレクトURI）］：OktaがOAuthレスポンスを返す送信先です。1つ以上のURIを入力します。
  • ［Sign-out redirect URIs（サインアウトリダイレクトURI）］：証明書利用者からサインアウトして、エンドユーザーのセッションが終了した後に、ブラウザーでOktaのリダイレクト先となる場所です。1つ以上のURIを入力します。

  • ［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スコープを選択します。
      • ［Implicit（暗黙）］：設定ページの下部に［App Embed Link（アプリの埋め込みリンク）］セクションが表示されます。ここには、Oktaの外部からOIDCクライアントにサインインする場合に利用できるURLが表示されます。
    • ［Initiate login URI（ログイン開始のURI）］：サインインリクエストの開始に使用するURIです。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが認可要求を送信します。URIを入力または変更します。
  • ［Save（保存）］をクリックします。

シングルページアプリ

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

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

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

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

  • ［Proof Key for Code Exchange (PKCE)］：クライアントリクエストを確認するためにPKCEコードチャレンジが必要かどうかを示します。認証方法として［None（なし）］を選択すると、デフォルトでPKCEチャレンジが必要になります。PKCEコードの検証は、［Client secret（クライアントシークレット）］と［Public key / Private key（公開鍵/秘密鍵）］の両方の認証方法のオプションです。クライアントの認証方法を変更したときは、既存のシークレットとキーへの影響について「クライアント認証方法を変更する」を参照してください。

  • ［Save（保存）］をクリックします。

［一般設定］セクションでは、次の設定を構成できます。

［アプリケーション］ セクションで、アプリの詳細を構成します。

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

  • ［Grant type（付与タイプ）］：以下の付与タイプを選択します。

    • ［Authorization Code（認可コード）］：認可コードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Refresh Token（リフレッシュトークン）］：使用するたび、または永続的トークンを使用するたびにトークンをローテーションします。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
    • ［Device Authorization（デバイス認可）］：デバイス認可は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Implicit (hybrid)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。使用するトークンのタイプを選択します。
      • Allow ID token with implicit grant type（暗黙の付与タイプでIDトークンを許可）
      • Allow Access token with implicit grant type（暗黙の付与タイプでアクセストークンを許可）
  • ［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］：このオプションを選択すると、トークンリクエストでクライアントに公開鍵と秘密鍵のペアを所有していることの証明が要求されます。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。DPoPを必須とするときは、［付与タイプ］オプションの［Implicit (hybrid)（暗黙（ハイブリッド））］を選択できません。

［ユーザーの同意］セクションで、OIDC統合のユーザー同意を追加または削除します。

  • ［User Consent（ユーザーの同意）］：
    • ［Require consent（同意が必要）］：このオプションを選択すると、統合が特定のリソースにアクセスすることの承認を促すポップアップウィンドウがユーザーに表示されます。「APIアクセススコープを作成する」で説明されているように、OIDCスコープへの同意はカスタム認可にセットアップできます。このチェックボックスは、orgにOkta API Access Managementが有効な場合にのみ表示されます。詳細については、「ユーザーの同意を要求する」を参照してください。
    • ［Terms of Service URI（利用規約のURI）］：同意ポップアップウィンドウに表示する利用規約テキストの保管場所のリンクを貼り付けます。
    • ［Policy URI（ポリシーのURI）］：同意ポップアップ ウィンドウに表示するポリシーテキストの保管場所のリンクを貼り付けます。
    • ［Logo URI（ロゴのURI）］：同意ポップアップ ウィンドウに表示するロゴの保管場所のリンクを貼り付けます。背景が透明な横長の.png画像を使用すると最適になります。拡大されることがないように、420 x 120ピクセル以上の解像度を使用します。

［Login（ログイン）］セクションで、サインインの詳細を構成します。

  • ［ログイン］：アプリのサインインとサインアウトにURIを構成します。
    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：OktaがOAuthレスポンスを返す送信先です。1つ以上のURIを入力します。
    • ［Sign-out redirect URIs（サインアウトリダイレクトURI）］：証明書利用者からサインアウトして、エンドユーザーのセッションが終了した後に、ブラウザーでOktaのリダイレクト先となる場所です。1つ以上のURIを入力します。
  • ［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スコープを選択します。
      • ［Implicit（暗黙）］：設定ページの下部に［App Embed Link（アプリの埋め込みリンク）］セクションが表示されます。ここには、Oktaの外部からOIDCクライアントにサインインする場合に利用できるURLが表示されます。
    • ［Initiate login URI（ログイン開始のURI）］：サインインリクエストの開始に使用するURIです。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが承認要求を送信します。URIを入力または変更します。
  • ［Save（保存）］をクリックします。

ネイティブアプリ

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

  • ［Client ID（クライアントID）］：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。
  • ［Client authentication（クライアント認証）］：クライアント認証に使用する方法を選択します。
    • ［None（なし）］：このオプションはネイティブアプリで推奨されます。このオプションでは、追加検証のために［Proof Key for Code Exchange（PKCE）］が必要です。PKCEにより、アクセストークンをリクエストしたクライアントのみがトークンを取得できます。
    • ［Client secret（クライアントシークレット）］：パネルを表示して、クライアントが使用するシークレットを生成します。この値は、Oktaとアプリの統合にのみ認識されます。［Save（保存）］をクリックして、クライアントシークレットを生成します。クライアントシークレットを表示またはコピーできます。第2のクライアントシークレットがあれば、ステータスを変更してアクティブなシークレットを選択できます。「第2のクライアントシークレットを作成してクライアントシークレットをローテーションする」を参照してください。
    • ［Public key / Private key（公開鍵/秘密鍵）］：クライアント接続で使用する公開鍵と秘密鍵のペアを生成または追加するためのパネルが表示されます。「OIDCアプリのシークレットとキーを管理する」を参照してください。
  • ［Proof Key for Code Exchange (PKCE)］：クライアントリクエストを確認するためにPKCEコードチャレンジが必要かどうかを示します。認証方法として［None（なし）］を選択すると、デフォルトでPKCEチャレンジが必要になります。PKCEコードの検証は、［Client secret（クライアントシークレット）］と［Public key / Private key（公開鍵/秘密鍵）］の両方の認証方法のオプションです。クライアントの認証方法を変更したときは、既存のシークレットとキーへの影響について「クライアント認証方法を変更する」を参照してください。
  • ［Save（保存）］をクリックします。

［一般設定］セクションでは、次の設定を構成できます。

［アプリケーション］ セクションで、アプリの詳細を構成します。

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

  • ［Grant type（付与タイプ）］：以下の付与タイプを選択します。

    • ［Authorization Code（認可コード）］：認可コードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Interaction Code（インタラクションコード）］：インタラクションコードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Refresh Token（リフレッシュトークン）］：使用するたび、または永続的トークンを使用するたびにトークンをローテーションします。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
    • ［Resource Owner Password（リソース所有者のパスワード）］：リソース所有者のパスワードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［SAML 2.0 Assertion（SAML 2.0アサーション）］：SAML 2.0アサーションは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Device Authorization（デバイス認可）］：デバイス認可は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Token Exchange（トークンの交換）］：トークンの交換は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
    • ［Implicit (hybrid)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。使用するトークンのタイプを選択します。
      • Allow ID token with implicit grant type（暗黙の付与タイプでIDトークンを許可）
      • Allow Access token with implicit grant type（暗黙の付与タイプでアクセストークンを許可）
  • ［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］：このオプションを選択すると、トークンリクエストでクライアントに公開鍵と秘密鍵のペアを所有していることの証明が要求されます。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。DPoPを必須とするときは、［付与タイプ］オプションの［Implicit (hybrid)（暗黙（ハイブリッド））］を選択できません。

［User Consent（ユーザーの同意）］セクションで、OIDC統合のユーザー同意を追加または削除します。

  • ［User Consent（ユーザーの同意）］：
    • ［Require consent（同意が必要）］：このオプションを選択すると、統合が特定のリソースにアクセスすることの承認を促すポップアップウィンドウがユーザーに表示されます。「APIアクセススコープを作成する」で説明されているように、OIDCスコープへの同意はカスタム認可にセットアップできます。このチェックボックスは、orgにOkta API Access Managementが有効な場合にのみ表示されます。詳細については、「ユーザーの同意を要求する」を参照してください。
    • ［Terms of Service URI（利用規約のURI）］：同意ポップアップウィンドウに表示する利用規約テキストの保管場所のリンクを貼り付けます。
    • ［Policy URI（ポリシーのURI）］：同意ポップアップ ウィンドウに表示するポリシーテキストの保管場所のリンクを貼り付けます。
    • ［Logo URI（ロゴのURI）］：同意ポップアップ ウィンドウに表示するロゴの保管場所のリンクを貼り付けます。 背景が透明な横長の.png画像を使用すると最適になります。拡大されることがないように、420 x 120ピクセル以上の解像度を使用します。

［Login（ログイン）］セクションで、サインインの詳細を構成します。

  • ［ログイン］：アプリのサインインとサインアウトにURIを構成します。
    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：OktaがOAuthレスポンスを返す送信先です。1つ以上のURIを入力します。
    • ［Sign-out redirect URIs（サインアウトリダイレクトURI）］：証明書利用者からサインアウトして、エンドユーザーのセッションが終了した後に、ブラウザーでOktaのリダイレクト先となる場所です。1つ以上のURIを入力します。
    • ［Initiate login URI（ログイン開始のURI）］：サインインリクエストの開始に使用するURIです。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが認可要求を送信します。URIを入力または変更します。
  • ［Save（保存）］をクリックします。

任意の設定を構成する

任意で、グループクレームフィルターの構成、エンタイトルメントの構成、アプリのレート制限の設定、発行者の設定を行うことができます。

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

  1. ［サインオン］タブに移動し、下にスクロールして［OpenID Connect IDトークン］セクションに移動します。

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

    以下の条件が両方とも構成にある場合には、APIはIDトークンを作成できません：

    • グループクレームフィルターと一致するグループが100以上ある。
    • ［Authorization Code（認可コード）］や［Authorization Code with PKCE（PKCE付き認可コード）］ではない付与タイプを使用している。

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

エンタイトルメントを構成する

エンタイトルメントSAMLアサーションとOIDCクレーム機能を有効にしている場合、Identity Governance and Administration（IGA）アプリ統合を変更すると、このオプションが表示されます。

「フェデレーションクレームを生成する」を参照してください。

アプリレート制限を設定する

個々のOAuth 2.0アプリのレート制限を構成できます。デフォルトでは、すべての新規アプリはすべてのAPIのレート制限の50%を消費します。

  1. ［アプリケーションレート制限］タブの［Edit（編集）］をクリックします。
  2. 目的のパーセンテージになるようにスライダーを移動します。
  3. ［Save（保存）］をクリックします。

「レート制限ダッシュボード」を参照してください。

発行者を設定する

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

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

次の手順