OIDCアプリ統合を作成する

OpenID Connect（OIDC）によるアプリ統合では、OAuth 2.0プロトコル上に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トークンを送信する宛先です。

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

コンテキスト

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

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

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

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

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

  1. Admin Consoleで［Applications（アプリケーション）］［Applications（アプリケーション）］に移動します。
  2. ［Create App Integration（アプリ統合を作成）］ をクリックします。
  3. OIDCアプリの統合を作成するには、［Sign-in method（サインイン方法）］として［OIDC - OpenID Connect］を選択します。
  4. Oktaと統合するアプリケーションのタイプを選択します。［Web Application（Webアプリケーション）］、［Single-Page Application（シングルページアプリケーション）］、［Native Application（ネイティブアプリケーション）］のいずれかを選択します。
  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ピクセル以上の解像度を使用してください。
    • ［Grant type（付与タイプ）］：さまざまな付与タイプオプションから選択します。アプリ統合に使用できる付与タイプは、選択したプラットフォームによって異なります。「OAuth 2.0とOpenID Connectの概要」を参照してください。

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

        早期アクセスリリース。「早期アクセス機能とBeta機能を管理する」を参照してください。

    • ［Sign-in redirect URIs（サインインリダイレクトURI）］：サインインリダイレクトURIとは、Oktaがサインインリクエストの認証レスポンスとIDトークンを送信する宛先です。URIは絶対URIでなければなりません。

      複数のURIを指定できます。OIDCアプリケーションは、使用するredirect_uriを明示的に要求する必要があり、URIはどのような順序でも指定可能です。OIDCアプリケーションが、統合に登録されていない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コードチャレンジが必要かどうかを示します。これは［クライアントシークレット］と［公開鍵/秘密鍵］の両方の認証方法のオプションです。

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

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

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

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

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

      • ［Client credentials（クライアント資格情報）］：資格情報は、それ自体の代わりに機能するクライアントの付与タイプとして使用されます。
      • ［Authorization code（認証コード）］：認証コードは、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
      • ［Refresh Token（リフレッシュトークン）］：使用するたび、または永続的トークンを使用するたびにトークンをローテーションします。使用のたびにトークンをローテーションする場合、そのトークンをアクティブにしておく期間を設定できます。
      • ［Device Authorization（デバイス認証）］：デバイス認証は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。
      • ［Implicit (hybrid)（暗黙（ハイブリッド））］：暗黙は、ユーザーの代わりに機能するクライアントの付与タイプとして使用されます。使用するトークンのタイプを以下から選択します。
        • ［Allow ID token with implicit grant grant type（暗黙の付与タイプでIDトークンを許可）］
        • ［Allow Access token with implicit grant type（暗黙の付与タイプでアクセストークンを許可）］

      • Client Initiated Backchannel認証フロー（CIBA）付与タイプを選択する場合は、［Preferred authenticator for CIBA（CIBAの推薦Authenticator）］も選択する必要があります。ドロップダウンメニューから既存のAuthenticatorを選択するか、［custom authenticator（カスタムAuthenticator）］をクリックして［Authenticators］インターフェイスを開きます。「カスタム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ヘッダーがないトークンリクエストを拒否します。また、［Grant type（付与タイプ）］オプションで［Client credentials（クライアントの資格情報）］または［Implicit (hybrid)（暗黙（ハイブリッド））］を選択できなくなります。

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

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

    • 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（保存）］をクリックして、［クライアントの認証情報］の変更を確定します。クライアントの認証方法を変更したときは、既存のシークレットとキーへの影響について「クライアント認証方法を変更する」を参照してください。

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

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

    • クライアントにトークンリクエストで公開/秘密鍵のペアを所有していることを証明するよう要求するには、［Require Demonstration of Proof-of-Possession (DPoP) header in token requests（トークンリクエストでの所有証明（DPoP）ヘッダーのデモを必須にする）］を選択します。認可サーバーは、このクライアントからのDPoPヘッダーがないトークンリクエストを拒否します。また、［Grant type（付与タイプ）］オプションで［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つ以上入力します。

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

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

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

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

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

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

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

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

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

アプリケーションレート制限を設定する

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

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

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

発行者を設定する

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

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

次の手順