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トークンを作成し、対象アプリに登録されている最初のredirect URIに直接ポストします。このフローは、SAMLアプリのサインインリクエストの場合と同じです。また、付与するOIDCスコープを構成できます。このフローではform_postレスポンスモードが使用されます。このリクエストは一方向で行われるため、リクエスト内に状態パラメーターがありません。
リダイレクトUniform Resource Identifier（URI）のエンドポイントが機能していることを確認します。リダイレクトURIとは、Oktaが認証レスポンスとIDトークンを送信する宛先です。
アプリ統合に手順指示へのリンクが含まれるときは、cookieを常時利用できるサイトのリストにOktaを追加してアクセスに関する問題を回避します。「サードパーティクッキーを許可する」を参照してください。

ウィザードを起動する

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

一般設定を構成する

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

一般設定（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)）オプションのImplicit (hybrid)（暗黙（ハイブリッド））（Grant type）は選択できません。
- 付与タイプ（Grant type）：使用する付与タイプを選択します。その他の付与タイプを表示するには、詳細設定（Advanced）をクリックします。各付与タイプの説明については、「直接認証付与タイプを構成する」を参照してください。アプリ統合に使用できる付与タイプは、選択するプラットフォームによって異なります。「OAuth 2.0とOpenID Connectの概要」を参照してください。
- サインインリダイレクトURI（Sign-in redirect URIs）：Oktaがサインインリクエストの認証レスポンスとIDトークンを返す送信先です。URIは絶対URIである必要があります。
  複数のURIを指定して、任意の順序に並べ替えることができます。統合に登録されていないURIへのサインインを試みるユーザーには、エラーメッセージが表示されます。
  
  複数のサブドメインをサポートするようにOIDCクライアントが構成されている場合、1つのリダイレクトURIをワイルドカードで指定できます。サインインリダイレクトURIのワイルドカードを許可する（Allow wildcard in sign-in redirect URI）を選択してください。ワイルドカードの構成ガイドについては、「アプリのAPI」を参照してください。
  
  注意:
  サブドメインへのワイルドカードの使用は推奨されません。悪意のあるアクターが、トークンや認可コードを、予期せぬページや攻撃者が制御するページに送信する恐れがあるからです。
- 任意。サインアウトリダイレクトURI（Sign-out redirect URIs）：アプリがOktaにユーザーセッションのクローズを要求すると、OktaはユーザーをこのURIにリダイレクトします。URIは絶対URIである必要があります。複数のURIを指定できます。サインアウトリダイレクトURIでは、サブドメインにワイルドカードを使用できません。
信頼済みオリジン（Trusted Origins）：Webおよびネイティブアプリの統合にオプションを構成します：

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

注:

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

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

OIDC設定を構成する

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

Webアプリ

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

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

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

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

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

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

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

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

ログイン（Login）：アプリのサインインとサインアウトにURIを構成します。
サインインリダイレクトURI（Sign-in redirect URIs）：OktaがOAuthレスポンスを返す送信先です。1つ以上のURIを入力します。
サインアウトリダイレクトURI（Sign-out redirect URIs）：証明書利用者からサインアウトして、エンドユーザーのセッションが終了した後に、ブラウザーでOktaのリダイレクト先となる場所です。1つ以上のURIを入力します。
ログイン開始元（Login initiated by）：アプリがバックグラウンドでサインインプロセスを開始するか、アプリまたはOktaがサインインリクエストを開始するかを指定します。
- アプリのみ（App Only）：アプリがバックグラウンドで開始され、Oktaタイルは表示されません。
- Oktaまたはアプリのいずれか（Either Okta or App）：アプリ統合がOktaタイルを使用します：
  - アプリケーションの可視性（Application visibility）：アプリをエンドユーザーに見せるかを選択します。
  - ログインフロー（Login flow）：次のオプションを選択します：
  - Send ID Token directly to app (Okta Simplified)（IDトークンをアプリへ直接送信（Okta簡略化））：フローにOIDCスコープを選択します。
  - 暗黙（Implicit）：設定ページの下部にアプリの埋め込みリンク（App Embed Link）セクションが表示されます。ここには、Oktaの外部からOIDCクライアントにサインインする場合に利用できるURLが表示されます。
ログイン開始のURI（Initiate login URI）：サインインリクエストの開始に使用するURIです。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが承認要求を送信します。URIを入力または変更します。

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

シングルページアプリ

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

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

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

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

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

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

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

ユーザーの同意（User Consent）：

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

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

ログイン（Login）：アプリのサインインとサインアウトにURIを構成します。
- サインインリダイレクトURI（Sign-in redirect URIs）：OktaがOAuthレスポンスを返す送信先です。1つ以上のURIを入力します。
- サインアウトリダイレクトURI（Sign-out redirect URIs）：証明書利用者からサインアウトして、エンドユーザーのセッションが終了した後に、ブラウザーでOktaのリダイレクト先となる場所です。1つ以上のURIを入力します。
ログイン開始元（Login initiated by）：アプリがバックグラウンドでサインインプロセスを開始するか、アプリまたはOktaがサインインリクエストを開始するかを指定します。
- アプリのみ（App Only）：アプリがバックグラウンドで開始され、Oktaタイルは表示されません。
- Oktaまたはアプリのいずれか（Either Okta or App）：アプリ統合がOktaタイルを使用します：
  - アプリケーションの可視性（Application visibility）：アプリをエンドユーザーに見せるかを選択します。
  - ログインフロー（Login flow）：次のオプションを選択します：
  - Send ID Token directly to app (Okta Simplified)（IDトークンをアプリへ直接送信（Okta簡略化））：フローにOIDCスコープを選択します。
  - 暗黙（Implicit）：設定ページの下部にアプリの埋め込みリンク（App Embed Link）セクションが表示されます。ここには、Oktaの外部からOIDCクライアントにサインインする場合に利用できるURLが表示されます。
ログイン開始のURI（Initiate login URI）：サインインリクエストの開始に使用するURIです。Oktaがこのエンドポイントにリダイレクトされると、これがトリガーとなり、クライアントが承認要求を送信します。URIを入力または変更します。

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

ネイティブアプリ

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

クライアントID（Client ID）：すべてのOAuthフローに必要な公開IDです。この識別子は、アプリの統合を作成するときにランダムに生成されます。
クライアント認証（Client authentication）：クライアント認証に使用する方法を選択します。
- なし（None）：このオプションはネイティブアプリで推奨されます。このオプションでは、追加検証のためにProof Key for Code Exchange（PKCE）（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）セクションでは、次の設定を構成できます。

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

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

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

ユーザーの同意（User Consent）：

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

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

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

任意の設定を構成する

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

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

サインオン（Sign On）タブに移動し、下にスクロールしてOpenID Connect IDトークン（OpenID Connect ID Token）セクションに移動します。
グループクレームタイプ（Groups claim type）を選択します。既存グループのクレームをフィルター（Filter）することも、式（Expression）を選択して別グループのクレーム向けのカスタムフィルターを作成することもできます。
注:
以下の条件が両方とも構成にある場合には、APIはIDトークンを作成できません：
- グループクレームフィルター（Groups claim filter）と一致するグループが100以上ある。
- 認可コード（Authorization Code）やPKCE付き認可コード（Authorization Code with PKCE）ではない付与タイプを使用している。
SSOのグループクレームについては、「から返されるトークンのカスタマイズOkta 」を参照してください。

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

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

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

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

発行者を設定する

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

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

次の手順

統合が想定どおりに動作しないときは、 Oktaサポートまでお問い合わせください。
アプリケーションをユーザーに割り当てる
アプリ統合をグループに割り当てる
OINウィザードでSSO統合を送信する