OIDCアプリ統合を作成する

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

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

はじめに

  • アプリの統合のプラットフォームを決定します。利用できるプラットフォームは、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を追加してアクセスに関する問題を回避します。「サードパーティ製cookie廃止の影響を軽減する」を参照してください。

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

「同意」とは、スコープで保護されたリソースにアプリがアクセスすることを、ユーザーが明示的に許可することです。OAuth 2.0またはOpenID Connect認証フローの一部として、統合による指定リソースへのアクセスの承認をユーザーに促すことができます。また、統合作成の一部としてユーザーの同意をセットアップすることもできます。

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

アプリが新しいアクセストークンの取得を必要とする場合、ユーザーが特定のスコープに同意済みであれば、アプリがユーザーに同意を求める必要はありません。同意の付与は、ユーザーが手動で取り消すまで有効です。また、ユーザー、統合、認可サーバー、またはスコープが非アクティブ化または削除されるまで有効です。ユーザーの同意が機能するには、orgのAPIアクセス管理機能が有効化されている必要があります。

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

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

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

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

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

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

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

    • 任意。［Logo（ロゴ）］：Okta orgのアプリの統合に使用するロゴを追加します。ロゴのファイルは .png、.jpg、.gif形式のいずれかで、1MB未満である必要があります。背景が透明で横向きのPNG画像を使用すると、最適な効果を得られます。アップスケールを防ぐために、420 x 120ピクセル以上の解像度を使用してください。
    • ［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の概要」を参照してください。

      • Client Initiated Backchannel認証フロー（CIBA）付与タイプを選択する場合は、［CIBAの推奨Authenticator］も選択する必要があります。ドロップダウンメニューから既存のAuthenticatorを選択するか、［custom authenticator（カスタムAuthenticator）］をクリックして［Authenticator］インターフェイスを開きます。「カスタムAuthenticatorの構成」を参照してください。

    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：サインインリダイレクト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（割り当て）］：

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

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

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

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

タスク3：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（保存）］をクリックして［Client Credentials（クライアント資格情報）］の変更を確定します。クライアントシークレットと公開/秘密鍵の切り替えについては、「クライアント認証方法を変更する」を参照してください。

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

    • ［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（暗黙の付与タイプでアクセストークンを許可）

      • ［Client-initiated backchannel authentication flow (CIBA)（クライアント開始バックチャンネル認証フロー（CIBA））］付与タイプを選択するときは、［Preferred authenticator for CIBA（CIBAの推薦Authenticator）］も選択する必要があります。ドロップダウンメニューから既存のAuthenticatorを選択するか、［custom authenticator（カスタムAuthenticator）］をクリックして［Authenticator］インターフェイスを開きます。「カスタムAuthenticatorの構成」を参照してください。

    • OIDC統合向けのユーザー同意を追加または削除します。統合による特定リソースへのアクセスをユーザーに承諾するように促すポップアップウィンドウを表示するには、［Require consent（同意が必要）］を選択します。「APIアクセススコープを作成する」で説明されているように、OIDCスコープへの同意はカスタム認証にセットアップできます。［Require consent（同意が必要）］チェックボックスは、orgのOkta APIアクセス管理が有効な場合にのみ表示されることに注意してください。

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

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

      フロントチャネルシングルログアウトの早期機能を有効にした場合、この構成は変更されています。「OIDC統合でSLOを有効にする」を参照してください。

    • ［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がこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが承認要求を送信します。

    • ［Email Verification Experience（メール検証エクスペリエンス）］：この設定により、メールマジックリンクをAuthenticatorとして使用する際のエンドユーザーエクスペリエンスをカスタマイズできます。エンドユーザーがワンタイムマジックリンクをクリックして、組み込みのSign-In Widgetを使用する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（なし）］：SPA統合のデフォルト。このオプションでは、追加検証のために［Proof Key for Code Exchange（PKCE）］が必要です。PKCEにより、アクセストークンをリクエストしたクライアントのみがトークンを取得できます。

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

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

    • クライアントにトークンリクエストで公開/秘密鍵のペアを所有していることを証明するよう要求するには、［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］を選択します。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。DPoPを必須とするときは、［付与タイプ］オプションの［Client credentials（クライアント資格情報）］または［Implicit (hybrid)（暗黙（ハイブリッド））］は選択できません。

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

      • ［Authorization Code（認証コード）］：認証コードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
      • ［Refresh Token（リフレッシュトークン）］：使用するたび、または永続的トークンを使用するたびにトークンをローテーションします。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
      • ［Device Authorization（デバイス認証）］：デバイス認証は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
      • ［Implicit (hybrid)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。

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

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

      フロントチャネルシングルログアウトの早期機能を有効にした場合、この構成は変更されています。「OIDC統合でSLOを有効にする」を参照してください。

    • ［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（メール検証エクスペリエンス）］：この設定により、メールマジックリンクをAuthenticatorとして使用する際のエンドユーザーエクスペリエンスをカスタマイズできます。エンドユーザーがワンタイムマジックリンクをクリックして、組み込みのSign-In Widgetを使用する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 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（保存）］をクリックして、［Client Credentials（クライアントの認証情報）］の変更を確定します。クライアントの認証方法を変更したときは、既存のシークレットとキーへの影響について「クライアント認証方法を変更する」を参照してください。

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

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

    • クライアントにトークンリクエストで公開/秘密鍵のペアを所有していることを証明するよう要求するには、［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］を選択します。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。［付与タイプ］オプションの［Implicit (hybrid)（暗黙（ハイブリッド））］は選択できません。

    • 付与タイプをさまざまな［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)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。

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

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

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

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

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

オプションとしてグループクレームフィルターを構成し、アプリレート制限と発行者を設定できます。

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

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

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

    100を上回るグループが［Groups claim filter（グループクレームフィルター）］と一致し、付与タイプが認証コードでもPKCE付き認証コードでもない場合、APIがIDトークンの作成を試みるとエラーが生じます。

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

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

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

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

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

発行者を設定する

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

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

次の手順