
- Okta と Auth0 間の構成情報の交換を自動化することで、アプリケーション インスタンスのセットアップに必要な時間を短縮します。
- 機密性の高い設定データを安全かつ認可された形で共有するために OAuth 2.0 の同意フローを利用し、認証情報や構成設定に関連する潜在的なエラーを減らします。
- 連携のデプロイ プロセスを簡素化し標準化します。自動化されたワークフローにより、複数の顧客や環境にわたってアプリケーション連携を一貫性のある再現可能な形でデプロイでき、人的ミスの可能性を抑えつつスケーラブルなアプリケーション エコシステムを実現します。
- 手動セットアップの複雑さを排除し、Okta の顧客側管理者が Auth0 対応の OIN 連携インスタンスを迅速に追加できるようにします。
仕組み

- Okta 管理者が Okta ポータルにサインインし、OIN から Express Configuration 対応のアプリケーションを選択します。
- Okta 管理者が Sign On セクションに移動し、Express Configure SSO & UL を選択します。これにより、Auth0 Universal Login の画面にリダイレクトされます。

- Okta 管理者は、Express Configuration を実行する権限を持つアプリケーション ユーザーの認証情報を入力します。Auth0 では、これは 組織 のメンバーであり、組織ロール またはその他の認可方法を使用して Express Configuration を実行することが許可されているユーザーを指します。

- 認証後、Auth0 は Okta 管理者に同意を求めます。

- 同意後、Okta は Express Configuration API を使用して、Okta 管理者が所属する Auth0 組織内に Okta 接続を自動的に構成します。
- その後、Okta 管理者はアプリケーション インスタンスにユーザーを割り当て、シングル サインオンがすぐに動作することを確認できます。
- SCIM が有効になっている場合、Okta 管理者はアプリケーション詳細の Provisioning セクションに移動し、Express Configure SCIM を選択して SCIM を構成できます。
- Universal Logout が有効になっている場合、OpenID Connect 連携の一部として自動的に構成されます。
前提条件
- Super Admin ロール、または App および Org Admin ロールのいずれかの権限を持つ Okta Integrator Free Plan org。
- 必要な数の顧客に対して Okta 接続タイプおよび Organizations 機能を利用できる Auth0 サブスクリプション。
- Multi-Organization Architecture を使用して Auth0 と統合されている SaaS アプリケーション。
- これには、Auth0 でアプリケーションを Regular Web Application または Single-Page Application として登録し、各顧客が自分専用のアイデンティティ プロバイダーを使用してそのアプリケーションにサインインできるようにすることが含まれます。
- Express Configuration を使用する各顧客に対して、Auth0 Organization がデプロイ済みであるか、デプロイ可能であること。Organizations と組織ロールは、特定のユーザーが Express Configuration を実行し、自身が所属する組織内でのみ Okta 接続を作成できるようにするために使用されます。
- Auth0 テナントで、テナント設定の Enable Application Connections が無効になっている必要があります。
Tip: Auth0 Organizations と組織ロールを含むマルチテナントアーキテクチャを実装しているサンプルアプリケーションを確認するには、SaaStart リファレンスアプリケーションを参照してください。
Express Configuration 用にアプリケーションを設定する

- Initiate Login URI Template を持つ登録済みアプリケーション
- Connection プロファイル
- ユーザー属性プロファイル
- 組織ログイン設定
- 管理者ログインおよび同意設定
Initiate Login URI Template を使用してアプリケーションを登録する
- Auth0 Dashboard で、アプリケーションを Regular Web Application または Single-Page Application として登録します。
- 登録後、作成したアプリケーションを選択し、Okta Integration Network タブに移動して Express Configuration セットアップウィザードを開始します。
- Get Started を選択します。
- 前提条件を確認し、Continue を選択します。
- Initiate Login URI Template を登録します。このテンプレートでは、アプリケーション側にエンドポイントを実装し、エンドユーザーを認証のために Auth0 の
/authorizeエンドポイントへ自動的にリダイレクトします。ログインエンドポイントの例については、Express SDK Quickstart の/loginルートを確認してください。- アプリケーションインスタンスに対して Express Configuration が開始されると、Okta は Initiate Login URI Template を使用して、エンドユーザー ダッシュボード からアプリケーションを起動します。
- (任意) Auth0 の
/authorizeエンドポイントに対して、どの組織または接続を使用するかを特定するためにorganization_name、organization_id、connection_nameを設定します。Okta は、エンドユーザー ダッシュボードから URL が起動されたときに、これらの変数を動的に置き換えます。例:https://{organization_name}.your-app.com?connection={connection_name}。

https://your-app.com/login https://your-app.com/login?connection={connection_name} https://{organization_name}.your-app.com?connection={connection_name} Connection プロファイル
- Auth0 内で接続名をどのように作成するかのオプション
- 接続で SCIM および/または Universal Logout を使用するためのオプション (推奨)
- 接続のエンドユーザーが、同意した管理者の組織のメンバーに自動的になることを許可するオプション
- Auth0 の Universal Login ページ上で、その接続に対する 「Show as button」 設定のオプション
Connection プロファイルが構成されていない場合、Auth0 は Express で構成された接続向けに、一般的かつ推奨される設定があらかじめ構成されたデフォルトの Connection プロファイルを提供します。
ユーザー属性プロファイル
User Attribute Profile が構成されていない場合、Auth0 は、Okta 接続タイプで使用される OpenID Connect および SCIM を含む、すべてのプロトコル向けに一般的かつ推奨されるマッピングを備えたデフォルトの User Attribute Profile を提供します。
組織ログイン設定
- アプリケーションで現在、Identifier-First ログインエクスペリエンスとホームレルム検出を使用している場合は、ホームレルム検出を有効化する方法について、Enabling Home Realm Discovery セクションを参照してください。
enabled_clientsで複数のアプリケーションを有効化し、それらを Express Configuration の Connection で使用できるようにしたい場合は、「Enabling Multiple Auth0 Applications Under a Single Integration」を参照してください。
enabled_clients 設定を使用してください。
管理者ログインと同意の設定
- Auth0 Dashboard > Applications に移動します。
- OIN に公開するアプリケーションを選択します。
- Okta Integration Network を選択します。
- 必要な前提条件が満たされていることを確認し、Continue を選択します。
- Configure Integration Profile セクションの Admin Settings でオプションを構成します。

- Admin Login Domain: Web ブラウザーでの同意フローの一部として、Okta がリダイレクトする Auth0 テナントドメインです。Auth0 でカスタムドメイン名を構成している場合は、そのカスタムドメイン名を使用します。詳細は、Custom Domains を参照してください。
- Display Name of the OIN Express Configuration Application: 同意ダイアログに表示される OIN クライアントアプリケーションの名前です。
-
Admin Login Flow: OIN クライアントアプリケーション用の Organization login フローを定義し、Okta 管理者が Okta コンソールから Express Configuration を実行する際に使用されます。次から選択します:
- Prompt for Organization: 最初に管理者が自分の組織を選択するよう求められ、その Auth0 組織のログインエクスペリエンスが表示されます。管理者は、その組織で構成されている既存の接続を使用してサインインできます。
- Prompt for Credentials: 最初に管理者がログイン資格情報の入力を求められます。このオプションを選択すると、管理者ユーザーを含む接続を選択できるボタンが表示されます。たとえば、共有データベース接続、パスワードレスのメール接続、またはすべての Auth0 組織に関連付けることができる別の接続にすることができます。
- Admin Role: Express Configuration を実行するには、管理者に適切な権限が割り当てられている必要があります。現在の Auth0 デプロイに最も適した方法で管理者を承認する手順については、Assign express configuration permissions to users を参照してください。
最適な同意エクスペリエンスのために、Customize Consent Prompts で説明されているとおり、テナントの
use_scope_descriptions_for_consent フラグを true に設定してください。統合をテストおよび検証する際に、同意プロンプトを確認する機会があります。ユーザーへの権限の割り当て
- 単一の Organization 専用として作成された専用データベース接続内のユーザー
- 1 つ以上の Organization のメンバーである、共有データベース接続内のユーザー
- 1 つ以上の Organization のメンバーである、パスワードレスのメール接続を持つユーザー
- 1 つ以上の Organization のメンバーである、ソーシャルまたは既存のエンタープライズ接続内のユーザー
| Method | Recommended for… |
|---|---|
| 既存のユーザーロールに Express Configuration の権限を割り当てる | Auth0 テナント内に既存のアプリケーションユーザーロールを持つお客様。 |
| SaaStart リファレンスアプリケーション で例示されているように、Express Configuration の権限を必要とするアプリケーションユーザーに新しいロールを割り当てる。 | Auth0 の ロール機能を使用して、個々のユーザーに Express Configuration の権限を付与したいお客様。これは Auth0 Dashboard または Management API を使用して実行できます。 |
| Post-Login Action を使用して、属性ベースのアクセス制御により動的に権限を割り当てる | 現在 Auth0 の ロール機能を使用しておらず、Auth0 Dashboard を使用したり、ロールを割り当てるために Management API 呼び出しを行うのではなく、ユーザー属性に基づいて動的に権限を割り当てるために Post-Login Action を使用したいお客様。 |
既存のアプリケーションユーザー ロールにパーミッションを割り当てる
| パーミッション名 | API(リソースサーバー)識別子 |
|---|---|
express_configure:sso | urn:auth0:express-configure |
express_configure:scim | urn:auth0:express-configure |
アプリケーションユーザーに新しいロールを割り当てる
ロールを作成する
ロールに権限を割り当てる
express_configuration:sso と express_configuration:scim の権限を割り当てます。$ROLE_ID を、権限を付与したいロール ID に置き換えてください。
この方法を使用する場合は、Express Configuration の権限が必要な新しい組織ユーザーにこのロールを割り当てられるよう、顧客向けオンボーディングプロセスを更新する必要があります。
ポストログイン Action を使用してユーザー属性に基づいて権限を割り当てる
次の例では、既存のカスタムユーザー属性
user.app_metadata.is_admin の値に基づいて権限を割り当てるために、ポストログイン Action を使用します。
ホーム レルム検出を有効にする
Express Configuration を実行する前に、HRD を有効にするための顧客オンボーディング プロセスの一環として、顧客のメールアドレスを収集し、検証しておく必要があります。
- 1 つ以上のメール ドメインを、顧客の Auth0 組織上の organization metadata に保存しておくことができます。
- ポストログイン Actions から API 呼び出しを行い、環境内で検証済みドメインを保存している任意のシステムから取得することができます。
この例では、検証済みドメインは Auth0 組織内の Connection メタデータに保存されています。この方法では、
domains という名前のキーの下に、1 つ以上のメール ドメインをカンマ区切りの文字列として organization metadata に保存しておく必要があります。
値の例: test.com,test2.com
この例では、ポストログイン Action が API 呼び出しを実行し、環境内のストレージシステムから検証済みドメインを取得します。
接続間での管理者アカウントの対応関係の維持
- Admin login and consent flow で Prompt for Organization オプションを使用します。
- プロビジョニング後、一致する検証済みメールアドレスを含む新しい Okta アカウントに対して、Express Configuration の権限を有効にします。
- Express Configuration の管理者同意フローにのみ Auth0 Organizations を使用し、アプリケーションでのエクスペリエンスには使用していない場合は、Configure SaaS Application Properties で説明されている
enable_organizationプロパティを無効にすることで、この問題を解決できます。 - 管理者ユーザーの識別子が、データベース接続のユーザー名など、メールアドレスではない場合は、この問題は発生しません。
単一のインテグレーションで複数のアプリケーションを有効にする
linked_clients プロパティを設定できます。
この設定を変更するには、Auth0 Management API を使用して登録済み Web アプリケーションを取得します。{yourAppId} を登録済みアプリケーションの Client ID に、{yourAccessToken} を Management API v2 アクセストークンに置き換えてください。Management API で使用するアクセストークンの取得方法については、「Management API Access Tokens」を参照してください。
express_configuration プロパティを取り出し、linked_clients プロパティに追加のアプリケーション ID の配列を設定して、登録済みのウェブアプリケーションを更新します:
enabled_clients プロパティに追加されます。
統合を OIN に公開する
- OIN にアプリケーションを登録する 2. Express Configuration 統合をリクエストする 3. OIN の公開鍵を設定する 4. Express Configuration 統合をテストして検証する 5. OIN への提出を完了する
OIN にアプリケーションを登録する
- テストに使用する、Auth0 対応の Web アプリケーションのインスタンス
- Okta Integrator Free Plan 組織(Super Admin ロール、または App および Org Admin ロールのいずれかへのアクセスが必要)
- 基本的なテストを完了するには、Okta Integrator Free Plan 組織を Auth0 テナント内の Okta 接続として構成し、Auth0 対応 Web アプリケーションで利用できるよう有効化しておく必要があります
- Okta Browser Plugin がインストールされている Google Chrome ブラウザー(OIN Wizard の要件を参照)
- サインアップ時に使用したユーザーアカウント、または Okta で
SUPER_ADMINロール、あるいはAPP_ADMINおよびORG_ADMIN管理者ロールが割り当てられているアカウントで Okta Integrator Free Plan 組織にサインインします。 - 管理コンソールで Applications > Your OIN Integrations に移動します。
- 新規アプリケーションの場合は Build new OIN integration を選択します。既存のアプリケーションの場合は、既存の OIN Integration を選択します。OIN Wizard が表示されます。

- Add integration capabilities で、SSO プロトコルとして OpenID Connect (OIDC) を選択します。
- 任意で Universal Logout と SCIM 2.0 を選択できます。どちらもすべての Okta 連携で強く推奨されており、Express Configuration でサポートされています。
- Configure your integration を選択します。
- OIN Catalog Properties セクションを必要に応じて入力します。参考として、OIN Catalog Properties を参照してください。
-
OIDC Properties で、次のフィールドを設定します。
A. Redirect URIs には、Auth0 テナントのコールバック URI を指定します。これはテナントのカスタムドメインまたは
auth0.comドメインのいずれかを使用できます。
例:https://tenant.auth0.com/login/callbackB. (任意) Initiate Login URI を、Auth0 のアプリケーションで設定した値と同じ値に設定します。詳細は「Auth0 アプリケーションおよび initiate login URI」で説明されています。Okta はこの URL を使用して、エンドユーザーダッシュボード からアプリケーションを起動します。
例:https://{organization_name}.your-app.com?connection={connection_name}C. (任意) Post-Logout URL を、アプリのサインアウト後リダイレクト URI に設定します。これは、エンドユーザーがアプリからサインアウトした後に遷移させたい場所です。テナントごとにサインアウト URI が異なる場合は、インテグレーション変数を使用できます。 D. Configuration guide URL を、Okta とアプリ間で Express Configuration を使って SSO を構成する方法に関する、顧客向け手順へのリンクに設定します。詳細については、Customer configuration document guidelines を参照してください。
-
Universal Logout を選択した場合は、「Universal logout properties」で次のフィールドを設定します。
A. Global token revocation エンドポイントを Auth0 テナント名に設定します。この値は Express Configuration の実行時に動的に置き換えられます。
B. Subject format で issuer を選択し、Subject identifier を選択します。
C. アプリケーションが Auth0 とアプリケーション間の OIDC back-channel ログアウトを使用していない一方で、アプリケーションがリフレッシュトークン を使用している場合は、Partial support にチェックを入れます。

-
SCIM 2.0 を選択した場合は、SCIM provisioning properties で次のフィールドを設定します。
A. Base URL を Auth0 テナント名に設定します。この値は Express Configuration の実行時に動的に置き換えられます。
B. User Operations で、Create、Update、Deactivate を選択します。
C. Okta とアプリ間で Express Configuration を使って SSO を構成する方法に関する、顧客向け手順へのリンクを設定します。詳細については、Customer configuration document guidelines を参照してください。

- Get started with testing を選択します。
- Request an express configuration integration セクションに進みます。
Express Configuration インテグレーションをリクエストする
expressconfig@okta.com の Okta Express Configuration チーム宛てにメールを送信します。
Express Configuration インテグレーションをリクエストするには:
- 使用するメールアプリケーションを開き、新規メールを作成します。
- 宛先に expressconfig@okta.com を入力します。
- 件名に Express configuration integration request と入力します。
- Auth0 Dashboard の Auth0 Dashboard > Applications > Okta Integration Network > Request Integration セクションに移動し、次の情報をメール本文にコピーします。

- Okta Free Integrator Org の名前(例:
trial-7513274)と、OIN Integration の Okta Display name をメール本文に記載します。 - メールを送信します。
OIN 公開鍵を設定する

統合をテストして検証する
- Okta OIN Operations チームと共有できる Auth0 組織とユーザー名/パスワードアカウントを作成します。
- この目的のために Auth0 組織とユーザー名/パスワードアカウントを作成するには、Example customer enablement flow の手順に従ってください。
- 必要に応じて、新しいアプリケーションテナントの作成など、テスト用の組織がログインできるようにアプリケーション側で必要となる追加作業を行ってください。
- テストアカウントを作成したら、
SUPER_ADMINロールを持つスーパー管理者、またはアプリ (APP_ADMIN) および組織 (ORG_ADMIN) 管理者 ロール のいずれかを持つユーザーとして Okta Integrator Free 組織にサインインします。 - Okta 管理コンソールで Applications > Your OIN Integrations に移動します。対象の OIN 統合を選択します。
- Configure your integration を選択します。続いて Get started with testing. を選択します。
- Account URL をアプリケーションのログインページに設定します。Okta OIN Operations エンジニアがこの URL にアクセスし、後続のフィールドで指定したアカウント認証情報を使用してアプリにサインインします。
- Username と Password に、Express Configuration のテスト用に設定したテスト用組織管理者アカウントのユーザー名とパスワードを指定します。
- Support Contact に、Okta が統合についてあなたの会社に連絡する際に使用するメールアドレスを設定します。このメールアドレスは OIN カタログや顧客には公開されません。Okta 社内チームにのみ表示されます。
- OIDC Tests セクションで、Just-In Time Provisioning についてはこのテストをスキップするために No を選択し、SP Initiate URL をアプリケーションインスタンスのログイン開始 URL に設定します。

- Test your integration を選択します。
- Generate Instance を選択し、続いて Done を選択します。
- Sign On タブに移動します。
- Single Sign-On と Universal Logout の Express Configuration をテストするには、Express Configure SSO & UL を選択します。

- Auth0 の Universal Login ページにリダイレクトされたら、組織管理者アカウントでサインインし、データ共有に同意します。
- SCIM をテストするには、Provisioning を選択し、続いて Express Configure SCIM を選択します。Auth0 の Universal Login にリダイレクトされたら、表示される同意プロンプトに従って進めます。完了すると、SCIM 統合が設定されます。
- 次に、Assignments タブを選択し、認証情報を把握している Okta Free Integrator 組織のユーザーを割り当てます。適切なユーザーが存在しない場合は、Add users manually の手順に従ってユーザーを追加します。SCIM が有効な場合、そのユーザーは Auth0 テナントにプロビジョニングされます。Auth0 Dashboard を使用して確認します。
- SSO をテストするには、今割り当てたユーザーアカウントとテストインスタンスを使用します。そのユーザーアカウントの認証情報でログインします。
- Universal Logout をテストするには、Test Universal Logout の手順に従ってください。
送信を完了する
- アプリケーションインスタンスで Begin Testing を選択し、送信を確定します。
- Express Configuration で直前にテストしたインスタンス名の横で Add to Tester を選択します。
- 自動 SSO テストを完了するには、IDP flow および/または SP flow テストで Run test を選択します。これらのテストには Okta ブラウザプラグインが必要です。詳細については、OIN Wizard Requirements を参照してください。
A. アプリケーションインスタンスに割り当てた Okta Free Integration Organization のユーザーでサインインします。プラグインがアプリケーションに正常にサインインできることを検出すると、テストは合格となります。これらのテストの詳細については、Test your integration を参照してください。
B. ログインテスト中に
invalid_request (no connections enabled for the client)というエラーメッセージを受け取った場合は、数分待ってから再試行してください。新しく作成した接続が HRD などの機能で利用可能になるまでには、数分かかることがあります。 - SCIM 用の必須 Runscope テストを完了するには、Okta SCIM 2.0 Spec Tests を使用し、Test your SCIM API の手順に従ってください。 A. 2 つ目の SCIM トークンは、Authentication > Enterprise > Okta > [your-express-configred-connection] > Provisioning > Sync user profiles using SCIM > Setup セクションから取得します。 B. 完了したら、共有可能な Runscope テスト URL を OIN Wizard の Link to Runscope spec test results と Link to Runscope CRUD test results フィールドに入力します。
- すべて完了したら、Submit Integration を選択します。
カスタマーイネーブルメント
顧客イネーブルメントフローの例
- 顧客の組織名
- Express Configuration を実行する権限を持つべき顧客管理者のメールアドレス
- 管理者のドメインを含む、ユーザーに対して顧客の IdP(アイデンティティプロバイダー)が発行する検証済みメールドメイン
- Auth0 Organization を作成します。
- データベースやメールパスワードレスなどの Auth0 の Connection に管理者ユーザーアカウントを作成します。
- Connection を Auth0 Organization に関連付けます。Membership On Authentication を無効にします。
- 管理者ユーザーアカウントを Auth0 Organization のメンバーとして追加します。
- Express Configuration を実行する権限を持つ組織ロールを管理者ユーザーに割り当てます。
Auth0 CLI の例
org_id を取得しておきます。
組織管理者アカウントを作成する
この例では、メールパスワードレス接続でユーザーを作成します。そのためには、email 接続タイプが必要です。このコマンドでは、Express Configuration の実行を許可するユーザーのメールアドレスを入力する必要があります。
ヒント
この Organization(組織)を Okta OIN オペレーションチーム向けのユーザー名とパスワードのテストアカウントを提供するために作成している場合は、共有または専用のデータベース接続のいずれかでテストアカウントを作成してください:
user_id を控えておきます。
接続を Organization(組織)に関連付ける
接続 ID を取得します:
org_id)に関連付けます。
org_id と user_id が必要です。
user_id と org_id に割り当てます。
管理者アカウントをプロビジョニングする際の推奨事項
仕事用メールを使用する
email 属性の値は、Okta Enterprise のユーザーアカウントとしてプロビジョニングされる、そのユーザーの勤務先メールアドレスと一致させるのが望ましいです(例: john@mycompany.com)。
Auth0 では、メール検証フロー を使用して、これらのメールアドレスを検証することを推奨しています。
MFA(多要素認証)を使用する
Express Configuration の使用状況を監視する
-
Auth0 Dashboard の Applications > [Application] > Okta Integration Network > Request Integration > Request Express Configuration セクション。
- Auth0 Management API でアプリケーションを表示したときの
express_configuration.okta_oin_client_idプロパティ。
- Auth0 Management API でアプリケーションを表示したときの
制限事項
- 1 つの OIN 統合で使用できる Auth0 テナントは 1 つのみです。同じアプリケーションを複数の Auth0 リージョンにデプロイする場合、各リージョンごとに独自の OIN 統合が必要です。
- 1 つの Okta 組織内の 1 つの OIN 統合につき、対応する 1 つの Auth0 組織内に 1 つの一意の Okta 接続のみを作成できます。1 つの Okta 組織内で複数の OIN アプリケーション インスタンスに対して Express 構成を使用することはできません。
- OIN に一覧表示されている一意の統合ごとに、独立した Okta 接続が作成されます。ホーム レルム検出を伴う Identifier-First ログイン エクスペリエンス を必要とするアプリケーションが複数ある場合は、単一の統合の下に複数のアプリケーションを公開することを推奨します。
- 単一の統合の下に複数のアプリケーションを有効にする場合、Okta は エンド ユーザー ダッシュボード にメイン OIN アプリケーションのみを表示します。
Management API reference
Okta OIN Express Configuration System API を作成する
ユーザー属性プロファイルの作成
GET /api/v2/user-attribute-profiles/templates エンドポイントを呼び出し、そのレスポンスボディをユーザー属性プロファイル作成呼び出しのリクエストボディとして使用します。
例:
Connection プロファイルを作成する
GET /api/v2/connection-profiles/templates エンドポイントを呼び出し、そのレスポンスを使用して Connection プロファイルを作成するリクエストボディを構成します。
例:
OIN Express Configuration クライアントを作成する
organization_require_behavior 属性は、以下のいずれかの値でカスタマイズできます。各値の説明については、管理者のログインと同意の設定を参照してください。
pre_login_prompt: 資格情報の入力を促す前に、管理者の所属組織を確認するプロンプトを表示します。post_login_prompt: 管理者の資格情報の入力を促すプロンプトを表示します。このオプションを使用する場合は、PATCH /api/v2/connections/{id}エンドポイントを使用して、管理者アカウントを含む接続のenabled_clientsプロパティに OIN クライアントのクライアントID を追加します。
SaaS アプリケーションのプロパティを構成する
express_configuration プロパティに対して、構成値を設定します。例中の値は、この連携で使用する有効な Connection プロファイル ID、User Attribute プロファイル ID、OIN クライアントアプリケーション ID、ログイン開始 URI、および Auth0 テナントドメインに置き換えてください。
linked_clients 属性は、単一の連携で複数のアプリケーションを有効化する で説明されている設定に対応します。
enable_client 属性は、組織のログイン設定 で説明されている enabled_clients の設定に対応します。
enable_organization 属性は、作成した接続を組織に割り当てない場合を除き、通常は true に設定してください。Okta アプリインスタンスは引き続き接続を管理できますが、Okta ユーザーは Auth0 組織のメンバーにはなりません。接続間で管理者アカウントの対応付けを維持する で説明されているケースでは、これを false に設定すると便利な場合があります。
例:
公開鍵をアップロードする
OIN クライアントアプリケーションにキーを割り当てる
yourCredentialId を、前の手順で取得したクレデンシャル ID に置き換えます。
例: