> ## Documentation Index > Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt > Use this file to discover all available pages before exploring further. > Auth0 と Okta Integration Network (OIN) を使用して Express Configuration を設定する方法について説明します。 # Okta を使用した Express Configuration [Okta Integration Network (OIN)](https://www.okta.com/integrations/) は、Okta が OpenID Connect によるシングルサインオン、SCIM による自動ユーザープロビジョニング、[Universal Logout](https://developer.okta.com/docs/guides/oin-universal-logout-overview) の有効化に向けた簡易かつ迅速なセットアップ エクスペリエンスを提供する SaaS アプリケーションのカタログです。Okta 管理者は、[Okta Admin Console](https://www.okta.com/okta-administrator-experience) を使用して、これらの連携機能を自社の Okta テナント内で設定します。 Okta Administrator Console Express Configuration により、エンタープライズ顧客はプロトコル固有の設定値をコピー＆ペーストすることなく、SaaS アプリケーションとのアイデンティティ連携を安全に構成できます。 Express Configuration は、Okta 管理者と SaaS アプリケーション開発者に次の利点を提供します。 * Okta と Auth0 間の構成情報の交換を自動化することで、アプリケーション インスタンスのセットアップに必要な時間を短縮します。 * 機密性の高い設定データを安全かつ認可された形で共有するために OAuth 2.0 の同意フローを利用し、認証情報や構成設定に関連する潜在的なエラーを減らします。 * 連携のデプロイ プロセスを簡素化し標準化します。自動化されたワークフローにより、複数の顧客や環境にわたってアプリケーション連携を一貫性のある再現可能な形でデプロイでき、人的ミスの可能性を抑えつつスケーラブルなアプリケーション エコシステムを実現します。 * 手動セットアップの複雑さを排除し、Okta の顧客側管理者が Auth0 対応の OIN 連携インスタンスを迅速に追加できるようにします。
## 仕組み
Express Configuration API を使用すると、顧客が OIN に公開されている Auth0 アプリケーションに対して、[Okta 接続](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta)で Express Configuration を利用できるようになります。Express Configuration は、Auth0 組織内での OpenID Connect、SCIM、Universal Logout をサポートします。 OIN 内の Auth0 アプリに対する Express Configuration のワークフローは次のとおりです。 OIN 内の Auth0 アプリ向け Express Configuration ワークフロー * Okta 管理者が Okta ポータルにサインインし、OIN から Express Configuration 対応のアプリケーションを選択します。 * Okta 管理者が **Sign On** セクションに移動し、**Express Configure SSO & UL** を選択します。これにより、[Auth0 Universal Login](/docs/ja-JP/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/universal-experience#universal-login-experience) の画面にリダイレクトされます。 Okta 管理コンソール > Sign On > Express Configuration * Okta 管理者は、Express Configuration を実行する権限を持つアプリケーション ユーザーの認証情報を入力します。Auth0 では、これは [組織](/docs/ja-JP/manage-users/organizations) のメンバーであり、[組織ロール](/docs/ja-JP/manage-users/organizations/configure-organizations/add-member-roles) またはその他の認可方法を使用して Express Configuration を実行することが許可されているユーザーを指します。 Auth0 組織のログイン * 認証後、Auth0 は Okta 管理者に同意を求めます。 Auth0 同意画面 * 同意後、Okta は Express Configuration API を使用して、Okta 管理者が所属する Auth0 組織内に [Okta 接続](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta)を自動的に構成します。 * その後、Okta 管理者はアプリケーション インスタンスにユーザーを割り当て、シングル サインオンがすぐに動作することを確認できます。 Auth0 開発者は、SCIM と Universal Logout についても Express Configuration を利用できるように OIN 連携を構成することができます。いずれも有効化が推奨されます。 * SCIM が有効になっている場合、Okta 管理者はアプリケーション詳細の **Provisioning** セクションに移動し、**Express Configure SCIM** を選択して SCIM を構成できます。 * Universal Logout が有効になっている場合、OpenID Connect 連携の一部として自動的に構成されます。
## 前提条件
Express Configuration を有効にして OIN にアプリケーションを公開するには、次のものが必要です。 * Super Admin ロール、または App および Org Admin ロールのいずれかの権限を持つ [Okta Integrator Free Plan org](https://developer.okta.com/signup/)。 * 必要な数の顧客に対して Okta 接続タイプおよび Organizations 機能を利用できる [Auth0 サブスクリプション](https://auth0.com/pricing)。 * Multi-Organization Architecture を使用して Auth0 と統合されている SaaS アプリケーション。 * これには、Auth0 でアプリケーションを [Regular Web Application](/docs/ja-JP/get-started/auth0-overview/create-applications/regular-web-apps) または [Single-Page Application](/docs/ja-JP/get-started/auth0-overview/create-applications/single-page-web-apps) として登録し、各顧客が自分専用の[アイデンティティ プロバイダー](/docs/ja-JP/authenticate/enterprise-connections)を使用してそのアプリケーションにサインインできるようにすることが含まれます。 * Express Configuration を使用する各顧客に対して、[Auth0 Organization](/docs/ja-JP/manage-users/organizations) がデプロイ済みであるか、デプロイ可能であること。Organizations と組織ロールは、特定のユーザーが Express Configuration を実行し、自身が所属する組織内でのみ Okta 接続を作成できるようにするために使用されます。 * Auth0 テナントで、テナント設定の [Enable Application Connections](/docs/ja-JP/get-started/tenant-settings#recommended-settings) が無効になっている必要があります。 **Tip**: Auth0 Organizations と組織ロールを含むマルチテナントアーキテクチャを実装しているサンプルアプリケーションを確認するには、[SaaStart リファレンスアプリケーション](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/)を参照してください。
## Express Configuration 用にアプリケーションを設定する
Auth0 Dashboard は、Auth0 開発者がアプリケーションで Express Configuration を有効にし、それを OIN に公開するまでの手順を案内します。 エンドツーエンドのセットアップと公開プロセスを完了するには、本番 Auth0 テナントでの [Auth0 Admin ロール](/docs/ja-JP/get-started/manage-dashboard-access/feature-access-by-role) が必要です。 Auth0 Dashboard の OIN テナントで Express Configuration をセットアップするには、次の Auth0 コンポーネントを設定します。 * Initiate Login URI Template を持つ登録済みアプリケーション * Connection プロファイル * ユーザー属性プロファイル * 組織ログイン設定 * 管理者ログインおよび同意設定
### Initiate Login URI Template を使用してアプリケーションを登録する
1. Auth0 Dashboard で、アプリケーションを [Regular Web Application](/docs/ja-JP/get-started/auth0-overview/create-applications/regular-web-apps) または [Single-Page Application](/docs/ja-JP/get-started/auth0-overview/create-applications/single-page-web-apps) として登録します。 2. 登録後、作成したアプリケーションを選択し、**Okta Integration Network** タブに移動して Express Configuration セットアップウィザードを開始します。 3. **Get Started** を選択します。 4. 前提条件を確認し、**Continue** を選択します。 5. **Initiate Login URI Template** を登録します。このテンプレートでは、アプリケーション側にエンドポイントを実装し、エンドユーザーを認証のために Auth0 の `/authorize` エンドポイントへ自動的にリダイレクトします。ログインエンドポイントの例については、[Express SDK Quickstart](/docs/ja-JP/quickstart/webapp/express/interactive) の `/login` ルートを確認してください。 * アプリケーションインスタンスに対して Express Configuration が開始されると、Okta は **Initiate Login URI Template** を使用して、[エンドユーザー ダッシュボード](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm) からアプリケーションを起動します。 * (任意) Auth0 の `/authorize` エンドポイントに対して、どの組織または接続を使用するかを特定するために `organization_name`、`organization_id`、`connection_name` を設定します。Okta は、エンドユーザー ダッシュボードから URL が起動されたときに、これらの変数を動的に置き換えます。例: `https://{organization_name}.your-app.com?connection={connection_name}`。 Dashboard>Applications>OIN>URI-template **Initiate Login URI の例:** `https://your-app.com/login`
`https://your-app.com/login?connection={connection_name}`
`https://{organization_name}.your-app.com?connection={connection_name}`
#### Connection プロファイル
Initiate Login URI Template では、**Connection プロファイル** を追加できます。Connection プロファイル (CP) によって、Express Configuration を使用して接続を作成する際に、その接続のプライベート設定をどのように構成するかを Auth0 に指定できます。これには、接続が Auth0 の Universal Login および Organizations 機能とどのように連携するかを制御する設定が含まれます。 * Auth0 内で接続名をどのように作成するかのオプション * 接続で SCIM および/または Universal Logout を使用するためのオプション (推奨) * 接続のエンドユーザーが、同意した管理者の組織のメンバーに自動的になることを許可するオプション * Auth0 の Universal Login ページ上で、その接続に対する **「Show as button」** 設定のオプション Connection プロファイルが構成されていない場合、Auth0 は Express で構成された接続向けに、一般的かつ推奨される設定があらかじめ構成されたデフォルトの Connection プロファイルを提供します。 デフォルトの CP をカスタマイズする方法については、[Connection Profile](/docs/ja-JP/authenticate/enterprise-connections/connection-profile) を参照してください。
#### ユーザー属性プロファイル
Initiate Login URI Template では、**User Attribute Profile** を追加できます。User Attribute Profile (UAP) を使用すると、Auth0 の開発者は、Auth0 がサポートするさまざまなプロトコル間でユーザー属性を一貫して定義、管理、およびマッピングできます。Express Configuration と併用すると、User Attribute Profile によって、Express Configuration によって生成される Okta 接続に書き込まれる OpenID Connect および SCIM の属性マップをカスタマイズできます。 User Attribute Profile が構成されていない場合、Auth0 は、Okta 接続タイプで使用される OpenID Connect および SCIM を含む、すべてのプロトコル向けに一般的かつ推奨されるマッピングを備えたデフォルトの User Attribute Profile を提供します。 デフォルトの UAP のカスタマイズ方法については、[User Attribute Profile](/docs/ja-JP/authenticate/enterprise-connections/user-attribute-profile) を参照してください。
### 組織ログイン設定
Auth0 Organizations は、特定の組織のユーザーに対して分離された Connection を作成する権限を付与するためには必須ですが、既存のアプリケーションのログインフローを変更して[ビジネスユーザー向けの組織ベースのログインフロー](/docs/ja-JP/manage-users/organizations/configure-organizations/define-organization-behavior)をサポートすること自体には必須ではありません。 * アプリケーションで現在、[Identifier-First ログインエクスペリエンス](/docs/ja-JP/authenticate/login/auth0-universal-login/identifier-first)とホームレルム検出を使用している場合は、ホームレルム検出を有効化する方法について、[Enabling Home Realm Discovery](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-home-realm-discovery) セクションを参照してください。 * `enabled_clients` で複数のアプリケーションを有効化し、それらを Express Configuration の Connection で使用できるようにしたい場合は、「Enabling Multiple Auth0 Applications Under a Single Integration」を参照してください。 アプリケーションが現在、組織ベースのログインフローを使用していない場合は、**Enable this application for created connections** 設定を選択できます。有効にすると、Okta Connection 上の各 Express Configuration はアプリケーションに直接関連付けられます。この Connection では必須となる `enabled_clients` 設定を使用してください。 Express Configuration が有効な場合、Auth0 は Okta と Auth0 間の管理者同意フローで OIN によって使用される、追加のクライアントアプリケーション ID を作成します。Okta は、OIN に公開されているそれぞれ異なるアプリケーション統合ごとに 1 つずつ OIN クライアントを作成します。 OIN に公開したいアプリケーションで **Configure Integration Profile** セクションの設定を行い、管理者ログインと同意を構成します。 1. [Auth0 Dashboard > Applications](https://manage.auth0.com/dashboard/#/applications) に移動します。 2. OIN に公開するアプリケーションを選択します。 3. **Okta Integration Network** を選択します。 4. 必要な前提条件が満たされていることを確認し、**Continue** を選択します。 5. **Configure Integration Profile** セクションの **Admin Settings** でオプションを構成します。 Express Configuration 管理者設定 * **Admin Login Domain**: Web ブラウザーでの同意フローの一部として、Okta がリダイレクトする Auth0 テナントドメインです。Auth0 でカスタムドメイン名を構成している場合は、そのカスタムドメイン名を使用します。詳細は、[Custom Domains](docs/customize/custom-domains) を参照してください。 * **Display Name of the OIN Express Configuration Application**: 同意ダイアログに表示される OIN クライアントアプリケーションの名前です。 * **Admin Login Flow**: OIN クライアントアプリケーション用の [Organization login](/docs/ja-JP/manage-users/organizations/login-flows-for-organizations) フローを定義し、Okta 管理者が Okta コンソールから Express Configuration を実行する際に使用されます。次から選択します： * **Prompt for Organization**: 最初に管理者が自分の組織を選択するよう求められ、その Auth0 組織のログインエクスペリエンスが表示されます。管理者は、その組織で構成されている[既存の接続](/docs/ja-JP/manage-users/organizations/configure-organizations/enable-connections)を使用してサインインできます。 * **Prompt for Credentials**: 最初に管理者がログイン資格情報の入力を求められます。このオプションを選択すると、管理者ユーザーを含む接続を選択できるボタンが表示されます。たとえば、共有データベース接続、パスワードレスのメール接続、またはすべての Auth0 組織に関連付けることができる別の接続にすることができます。 * **Admin Role**: Express Configuration を実行するには、管理者に適切な権限が割り当てられている必要があります。現在の Auth0 デプロイに最も適した方法で管理者を承認する手順については、[Assign express configuration permissions to users](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#assign-permissions-to-users) を参照してください。 最適な同意エクスペリエンスのために、[Customize Consent Prompts](/docs/ja-JP/customize/login-pages/customize-consent-prompts) で説明されているとおり、テナントの `use_scope_descriptions_for_consent` フラグを `true` に設定してください。統合をテストおよび検証する際に、同意プロンプトを確認する機会があります。
## ユーザーへの権限の割り当て
Okta では、Auth0 を利用する SaaS アプリケーションの Express Configuration を実行するには、必要な権限を持つアプリケーションユーザーアカウントを管理者が保持している必要があります。 Auth0 では、Express Configuration で構成された接続が作成されている [Auth0 Organization](/docs/ja-JP/manage-users/organizations) のメンバーである限り、任意のアプリケーションユーザーにこの権限を付与できます。たとえば、次のような場合です。 * 単一の Organization 専用として作成された専用データベース接続内のユーザー * 1 つ以上の Organization のメンバーである、共有データベース接続内のユーザー * 1 つ以上の Organization のメンバーである、パスワードレスのメール接続を持つユーザー * 1 つ以上の Organization のメンバーである、ソーシャルまたは既存のエンタープライズ接続内のユーザー これらの条件を満たすと、Auth0 は Express Configuration の権限を割り当てるための柔軟な方法を提供し、開発者は現在の Auth0 デプロイメントに最も適した方法を選択できます。 | **Method** | **Recommended for...** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 既存のユーザーロールに Express Configuration の権限を割り当てる | Auth0 テナント内に既存のアプリケーションユーザー[ロール](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles)を持つお客様。 | | [SaaStart リファレンスアプリケーション](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/) で例示されているように、Express Configuration の権限を必要とするアプリケーションユーザーに新しいロールを割り当てる。 | Auth0 の [ロール](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles)機能を使用して、個々のユーザーに Express Configuration の権限を付与したいお客様。これは Auth0 Dashboard または Management API を使用して実行できます。 | | Post-Login Action を使用して、属性ベースのアクセス制御により動的に権限を割り当てる | 現在 Auth0 の [ロール](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles)機能を使用しておらず、Auth0 Dashboard を使用したり、ロールを割り当てるために Management API 呼び出しを行うのではなく、ユーザー属性に基づいて動的に権限を割り当てるために Post-Login Action を使用したいお客様。 | Express Configuration に使用する管理者アカウントのプロビジョニングに関するヒントについては、[Customer Enablement](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#customer-enablement) を参照してください。
### 既存のアプリケーションユーザー ロールにパーミッションを割り当てる
アプリケーション ロールと API パーミッションに [Auth0 の RBAC 機能](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles) を使用していて、アプリケーションをデプロイする IT 管理者に割り当てる管理者ユーザーを表すロールが 1 つ以上既に存在する場合は、この方法で Express Configuration のパーミッションを割り当ててください。 必要な API パーミッション: | **パーミッション名** | **API（リソースサーバー）識別子** | | ------------------------ | ----------------------------- | | `express_configure:sso` | `urn:auth0:express-configure` | | `express_configure:scim` | `urn:auth0:express-configure` | Auth0 Dashboard と Management API でロールにパーミッションを割り当てる方法の詳細は、[ロールにパーミッションを追加する](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles/add-permissions-to-roles)を参照してください。
### アプリケーションユーザーに新しいロールを割り当てる
アプリケーションのロールや API パーミッションに [Auth0 の RBAC 機能](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles) を使用しているものの、IT 管理者などアプリケーションのデプロイを担当する管理者ユーザーを表すロールが存在しない場合は、この方法で Express Configuration のパーミッションを割り当ててください。 この方法は、現在は [Auth0 の RBAC 機能](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles) を使用していないものの、Auth0 Dashboard または Management API を使用して、どのユーザーにアクセスを許可するかをきめ細かく制御するために、この機能を活用したい Auth0 を利用する開発者にも適しています。
#### ロールを作成する
Auth0 Dashboard、Management API、または [Auth0 CLI](https://auth0.github.io/auth0-cli/auth0_roles_create.html) のいずれかを使用して、[ロールを作成](/docs/ja-JP/manage-users/access-control/configure-core-rbac/roles/create-roles)します。次の例では、Auth0 CLI を使用します。 ```bash theme={null} auth0 roles create \ --name "EXPRESS_CONFIGURE_ADMIN_ROLE" \ --description "Administrator role for Express Configuration" ```
#### ロールに権限を割り当てる
指定したロールに `express_configuration:sso` と `express_configuration:scim` の権限を割り当てます。`$ROLE_ID` を、権限を付与したいロール ID に置き換えてください。 この方法を使用する場合は、Express Configuration の権限が必要な新しい組織ユーザーにこのロールを割り当てられるよう、顧客向けオンボーディングプロセスを更新する必要があります。 ```bash theme={null} auth0 roles permissions add "$ROLE_ID" \ --api-id "urn:auth0:express-configure" \ --permissions "express_configure:sso" ``` ```bash theme={null} auth0 roles permissions add "$ROLE_ID" \ --api-id "urn:auth0:express-configure" \ --permissions "express_configure:scim" ``` 既存の組織内ユーザーにロールを割り当てる方法の詳細については、[メンバー ロールの追加](/docs/ja-JP/manage-users/organizations/configure-organizations/add-member-roles)を参照してください。
### ポストログイン Action を使用してユーザー属性に基づいて権限を割り当てる
Role-Based Access Control (RBAC)、Management API、または Auth0 Dashboard を使用してユーザーロールを割り当てる代わりに、Auth0 の[ポストログイン Action](/docs/ja-JP/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) を使用してユーザー属性に基づき動的に権限を割り当てる場合は、Express Configuration の権限を割り当てる方法としてこの手法を使用します。 これは、[Auth0 metadata](/docs/ja-JP/manage-users/user-accounts/metadata) 内のカスタム権限を使用した属性ベースの認可モデルで Auth0 をデプロイしている Auth0 のお客様に適しています。 **例**
次の例では、既存のカスタムユーザー属性 `user.app_metadata.is_admin` の値に基づいて権限を割り当てるために、ポストログイン Action を使用します。 ```bash theme={null} /** * ロール割り当てではなく、カスタムロジックに基づいてExpress Configuration権限を割り当てます */ exports.onExecutePostLogin = async (event, api) => { //check if request is for EC API access token if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") { //add permissions based on a custom condition if (event.user.app_metadata && event.user.app_metadata.is_admin === true) { api.accessToken.addScope("express_configure:sso"); api.accessToken.addScope("express_configure:scim"); } //else deny access if EC access token is requested else { api.access.deny('Access denied'); } } }; ```
## ホーム レルム検出を有効にする
Express Configuration を実行する前に、HRD を有効にするための顧客オンボーディング プロセスの一環として、顧客のメールアドレスを収集し、検証しておく必要があります。 アプリケーションが [Identifier-First ログイン エクスペリエンス](/docs/ja-JP/authenticate/login/auth0-universal-login/identifier-first) に依存し、メールアドレスに基づいてホーム レルム検出 (HRD) を使用し、ユーザーを IdP（アイデンティティプロバイダー）と照合している場合、Auth0 Actions と組み合わせて Express Configuration を使用できます。 メールアドレスは、Express Configuration ワークフロー中にポストログイン Actions からアクセスできる場所に保存しておく必要があります。たとえば次のような場所です。 * 1 つ以上のメール ドメインを、顧客の Auth0 組織上の [organization metadata](/docs/ja-JP/manage-users/organizations/configure-organizations/create-organizations) に保存しておくことができます。 * ポストログイン Actions から API 呼び出しを行い、環境内で検証済みドメインを保存している任意のシステムから取得することができます。 管理者ユーザーが Okta ポータルで Express Configuration を開始して認証を行うと、これらの Actions によって Okta が受け取るトークンにメール ドメインが追加されます。Okta はそのドメインを抽出して使用し、正しい HRD 構成で Okta 接続をセットアップします。 **例 1**
この例では、検証済みドメインは Auth0 組織内の Connection メタデータに保存されています。この方法では、`domains` という名前のキーの下に、1 つ以上のメール ドメインをカンマ区切りの文字列として organization metadata に保存しておく必要があります。 値の例: `test.com`,`test2.com` ```javascript theme={null} exports.onExecutePostLogin = async (event, api) => { if (event.request.query.audience === "urn:auth0:express-configure") { if (event.organization && event.organization.metadata && event.organization.metadata.domains) { var domain_aliases = event.organization.metadata.domains.replace(/ /g,'').split(','); var express_configuration = { "domain_aliases": domain_aliases }; api.accessToken.setCustomClaim("express_configuration", express_configuration); } } }; ``` **例 2**
この例では、ポストログイン Action が API 呼び出しを実行し、環境内のストレージシステムから検証済みドメインを取得します。 ```javascript theme={null} /** */ exports.onExecutePostLogin = async (event, api) => { if (event.request.query.audience === "urn:auth0:express-configure") { const axios = require("axios"); // カスタム API 呼び出しをここで設定します const domains = await axios.get("https://example.org/endpoint"); var express_configuration = { "domain_aliases": domains }; api.accessToken.setCustomClaim("express_configuration", express_configuration); } }; ```
### 接続間での管理者アカウントの対応関係の維持
Auth0 では、同じメールアドレスを使用して異なる接続にユーザーアカウントをプロビジョニングすることができます。エンドユーザーは、勤務先のメールアドレスでデータベース接続・ソーシャル・パスワードレスのいずれかのアカウントを持ち、さらに同じメールアドレスを連携された Okta アカウントでも使用することができます。 [Admin login and consent flow](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts) で **Prompt for Credentials** オプションを使用する場合、新しい Okta 接続が Organization に追加されると、ホームレルム検出は特定のドメインサフィックスを持つユーザーを、他の接続タイプではなく新しい Okta 接続に関連付けるようになります。この Organization のログイン動作について詳しくは、[Identifier First Authentication with prompt for credentials](/docs/ja-JP/manage-users/organizations/login-flows-for-organizations#identifier-first-authentication-with-prompt-for-credentials) を参照してください。 この挙動は、お客様が最初の Auth0 管理者ユーザーセッションの有効期限が切れた後に、Express Configuration を 2 回目に実行した場合にのみ有効になります。管理者アカウント識別子が新しい Okta 接続と一致するメールアドレスである場合、管理者はその接続へリダイレクトされます。 この挙動は、以下のいずれかの方法で制御または回避できます。 * [Admin login and consent flow](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts) で **Prompt for Organization** オプションを使用します。 * プロビジョニング後、一致する検証済みメールアドレスを含む新しい Okta アカウントに対して、Express Configuration の権限を有効にします。 * Express Configuration の管理者同意フローにのみ Auth0 Organizations を使用し、アプリケーションでのエクスペリエンスには使用していない場合は、[Configure SaaS Application Properties](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#configure-saas-application-properties) で説明されている `enable_organization` プロパティを無効にすることで、この問題を解決できます。 * 管理者ユーザーの識別子が、データベース接続のユーザー名など、メールアドレスではない場合は、この問題は発生しません。
## 単一のインテグレーションで複数のアプリケーションを有効にする
Okta 接続の単一の Express Configuration を利用するエンドユーザーに、テナント内の複数のアプリケーションへアクセスさせたい場合は、登録済み Web アプリケーションに `linked_clients` プロパティを設定できます。 この設定を変更するには、Auth0 Management API を使用して[登録済み Web アプリケーションを取得](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id)します。`{yourAppId}` を登録済みアプリケーションの Client ID に、`{yourAccessToken}` を Management API v2 アクセストークンに置き換えてください。Management API で使用するアクセストークンの取得方法については、「[Management API Access Tokens](/docs/ja-JP/secure/tokens/access-tokens/management-api-access-tokens)」を参照してください。 ```curl theme={null} curl --request GET \ --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \ --header 'authorization: Bearer {yourAccessToken}' ``` レスポンスから `express_configuration` プロパティを取り出し、`linked_clients` プロパティに追加のアプリケーション ID の配列を設定して、[登録済みのウェブアプリケーションを更新します](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id): ```curl theme={null} curl --request PATCH \ --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \ --data '{"express_configuration": {"admin_login_domain":"TENANT.auth0.com", "connection_profile_id":"cop_xxxxxxxxxxxxxxx", "enable_client":true, "enable_organization":true, "initiate_login_uri_template":"https://example.org", "okta_oin_client_id":"LDiGbUeiAYjRB5a4yOGfBvxxxxxxxxxxx", "user_attribute_profile_id":"uap_1ctMVQUg8jxxxxxxxxxxxx", "linked_clients": [ { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" } ] } }' \ --header 'cache-control: no-cache' \ --header 'content-type: application/json' \ --header 'authorization: Bearer {yourAccessToken}' ``` Express Configuration を実行すると、linked\_clients プロパティ内のすべてのアプリケーション ID が、Okta Connection の `enabled_clients` プロパティに追加されます。
## 統合を OIN に公開する
基本構成を作成したら、OIN への提出プロセスを開始する準備が整います。このプロセスの一環として、本番公開前に Express Configuration をエンドツーエンドで十分にテストできます。 1. OIN にアプリケーションを登録する 2\. Express Configuration 統合をリクエストする 3\. OIN の公開鍵を設定する 4\. Express Configuration 統合をテストして検証する 5\. OIN への提出を完了する
### OIN にアプリケーションを登録する
OIN の新規または既存のアプリケーションに Express Configuration を追加するには、次のものが必要です。 * テストに使用する、Auth0 対応の Web アプリケーションのインスタンス * [Okta Integrator Free Plan 組織](https://developer.okta.com/signup/)（Super Admin ロール、または App および Org Admin ロールのいずれかへのアクセスが必要） * 基本的なテストを完了するには、Okta Integrator Free Plan 組織を Auth0 テナント内の [Okta 接続](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta)として構成し、Auth0 対応 Web アプリケーションで利用できるよう有効化しておく必要があります * Okta Browser Plugin がインストールされている Google Chrome ブラウザー（[OIN Wizard の要件](https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-wizard-requirements)を参照） 1. サインアップ時に使用したユーザーアカウント、または Okta で `SUPER_ADMIN` ロール、あるいは `APP_ADMIN` および `ORG_ADMIN` 管理者ロールが割り当てられているアカウントで Okta Integrator Free Plan 組織にサインインします。 2. 管理コンソールで **Applications > Your OIN Integrations** に移動します。 3. 新規アプリケーションの場合は **Build new OIN integration** を選択します。既存のアプリケーションの場合は、既存の OIN Integration を選択します。OIN Wizard が表示されます。 Okta OIN を構成する 4. **Add integration capabilities** で、SSO プロトコルとして **OpenID Connect (OIDC)** を選択します。 5. 任意で **Universal Logout** と **SCIM 2.0** を選択できます。どちらもすべての Okta 連携で強く推奨されており、Express Configuration でサポートされています。 6. **Configure your integration** を選択します。 7. **OIN Catalog Properties** セクションを必要に応じて入力します。参考として、[OIN Catalog Properties](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#oin-catalog-properties) を参照してください。 8. **OIDC Properties** で、次のフィールドを設定します。

A. **Redirect URIs** には、Auth0 テナントのコールバック URI を指定します。これはテナントのカスタムドメインまたは `auth0.com` ドメインのいずれかを使用できます。
例: `https://tenant.auth0.com/login/callback`

B. (任意) **Initiate Login URI** を、Auth0 のアプリケーションで設定した値と同じ値に設定します。詳細は「Auth0 アプリケーションおよび initiate login URI」で説明されています。Okta はこの URL を使用して、[エンドユーザーダッシュボード](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm) からアプリケーションを起動します。
例: `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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines) を参照してください。 OIN OIDC Settings 9. **Universal Logout** を選択した場合は、「Universal logout properties」で次のフィールドを設定します。

A. **Global token revocation** エンドポイントを Auth0 テナント名に設定します。この値は Express Configuration の実行時に動的に置き換えられます。

B. **Subject format** で issuer を選択し、**Subject identifier** を選択します。

C. アプリケーションが Auth0 とアプリケーション間の [OIDC back-channel](https://auth0.com/docs/authenticate/login/logout/universal-logout#revoke-application-user-sessions) ログアウトを使用していない一方で、アプリケーションが[リフレッシュトークン](/docs/ja-JP/secure/tokens/refresh-tokens) を使用している場合は、**Partial support** にチェックを入れます。

Okta Admin Console Universal Logout Settings 10. **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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines) を参照してください。 OIN Express Configuration SCIM Provisioning 11. **Get started with testing** を選択します。 12. [Request an express configuration integration](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#request-an-express-configuration-integration) セクションに進みます。

## Express Configuration インテグレーションをリクエストする
登録済みの OIN Integration で Express Configuration 機能を有効にするには、Okta と Auth0 の両方のポータルからコピーした情報を含めて、`expressconfig@okta.com` の Okta Express Configuration チーム宛てにメールを送信します。 **Express Configuration インテグレーションをリクエストするには:** 1. 使用するメールアプリケーションを開き、新規メールを作成します。 2. 宛先に **[expressconfig@okta.com](mailto:expressconfig@okta.com)** を入力します。 3. 件名に **Express configuration integration request** と入力します。 4. Auth0 Dashboard の [Auth0 Dashboard > Applications > Okta Integration Network > Request Integration](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard) セクションに移動し、次の情報をメール本文にコピーします。 Dashboard > Applications > OIN > Request Integrations 5. Okta Free Integrator Org の名前（例: `trial-7513274`）と、OIN Integration の Okta Display name をメール本文に記載します。 6. メールを送信します。 メールを受信すると、Okta Express Configuration チームは登録済み OIN Integration に対して Express Configuration を有効化し、Auth0 Dashboard にアップロードする必要がある公開鍵を返信で送付します。
### OIN 公開鍵を設定する
前の手順で Okta Express Configuration チームから公開鍵を受け取ったら、Auth0 Dashboard の [Auth0 Dashboard > Applications > Okta Integration Network > Request Integration](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard) セクションにアップロードしてください。**Save** を選択します。 OIN Publc Key upload
### 統合をテストして検証する
公開鍵がアップロードされたら、Okta Free Integrator 組織を使用して Express Configuration をテストできます。 1. Okta OIN Operations チームと共有できる Auth0 組織とユーザー名/パスワードアカウントを作成します。 * この目的のために Auth0 組織とユーザー名/パスワードアカウントを作成するには、[Example customer enablement flow](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#example-customer-enablement-flow) の手順に従ってください。 * 必要に応じて、新しいアプリケーションテナントの作成など、テスト用の組織がログインできるようにアプリケーション側で必要となる追加作業を行ってください。 2. テストアカウントを作成したら、`SUPER_ADMIN` ロールを持つスーパー管理者、またはアプリ (`APP_ADMIN`) および組織 (`ORG_ADMIN`) 管理者 [ロール](https://developer.okta.com/docs/api/openapi/okta-management/guides/roles/#standard-roles) のいずれかを持つユーザーとして Okta Integrator Free 組織にサインインします。 3. Okta 管理コンソールで **Applications > Your OIN Integrations** に移動します。対象の OIN 統合を選択します。 4. **Configure your integration** を選択します。続いて **Get started with testing.** を選択します。 5. **Account URL** をアプリケーションのログインページに設定します。Okta OIN Operations エンジニアがこの URL にアクセスし、後続のフィールドで指定したアカウント認証情報を使用してアプリにサインインします。 6. **Username** と **Password** に、Express Configuration のテスト用に設定したテスト用組織管理者アカウントのユーザー名とパスワードを指定します。 7. **Support Contact** に、Okta が統合についてあなたの会社に連絡する際に使用するメールアドレスを設定します。このメールアドレスは OIN カタログや顧客には公開されません。Okta 社内チームにのみ表示されます。 8. **OIDC Tests** セクションで、Just-In Time Provisioning についてはこのテストをスキップするために **No** を選択し、**SP Initiate URL** をアプリケーションインスタンスのログイン開始 URL に設定します。 OIN integration OIDC test 9. **Test your integration** を選択します。 10. **Generate Instance** を選択し、続いて **Done** を選択します。 11. **Sign On** タブに移動します。 12. Single Sign-On と Universal Logout の Express Configuration をテストするには、**Express Configure SSO & UL** を選択します。 Express Configuration for SuperSaaS 13. Auth0 の Universal Login ページにリダイレクトされたら、組織管理者アカウントでサインインし、データ共有に同意します。 14. SCIM をテストするには、**Provisioning** を選択し、続いて **Express Configure SCIM** を選択します。Auth0 の Universal Login にリダイレクトされたら、表示される同意プロンプトに従って進めます。完了すると、SCIM 統合が設定されます。 15. 次に、**Assignments** タブを選択し、認証情報を把握している Okta Free Integrator 組織のユーザーを割り当てます。適切なユーザーが存在しない場合は、[Add users manually](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-users.htm) の手順に従ってユーザーを追加します。SCIM が有効な場合、そのユーザーは Auth0 テナントにプロビジョニングされます。Auth0 Dashboard を使用して確認します。 16. SSO をテストするには、今割り当てたユーザーアカウントとテストインスタンスを使用します。そのユーザーアカウントの認証情報でログインします。 17. Universal Logout をテストするには、[Test Universal Logout](/docs/ja-JP/authenticate/login/logout/universal-logout#test-universal-logout) の手順に従ってください。
### 送信を完了する
前のセクションで基本的なテストは完了しています。送信を確定するには、構成がいくつかの自動テストに合格する必要があります。 1. アプリケーションインスタンスで **Begin Testing** を選択し、送信を確定します。 2. Express Configuration で直前にテストしたインスタンス名の横で **Add to Tester** を選択します。 3. 自動 SSO テストを完了するには、**IDP flow** および/または **SP flow** テストで **Run test** を選択します。これらのテストには Okta ブラウザプラグインが必要です。詳細については、[OIN Wizard Requirements](https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-wizard-requirements) を参照してください。

A. アプリケーションインスタンスに割り当てた Okta Free Integration Organization のユーザーでサインインします。プラグインがアプリケーションに正常にサインインできることを検出すると、テストは合格となります。これらのテストの詳細については、[Test your integration](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#test-your-integration) を参照してください。

B. ログインテスト中に `invalid_request (no connections enabled for the client)` というエラーメッセージを受け取った場合は、数分待ってから再試行してください。新しく作成した接続が HRD などの機能で利用可能になるまでには、数分かかることがあります。

4. **SCIM** 用の必須 Runscope テストを完了するには、[Okta SCIM 2.0 Spec Tests](https://developer.okta.com/standards/SCIM/SCIMFiles/Okta-SCIM-20-SPEC-Test.json) を使用し、[Test your SCIM API](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#generate-an-instance-for) の手順に従ってください。

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** フィールドに入力します。

5. すべて完了したら、**Submit Integration** を選択します。

## カスタマーイネーブルメント
アプリケーションが OIN で公開されている場合は、製品ドキュメントを更新して、Okta の Express Configuration をサポートしていることを明記できます。製品ドキュメントには、どのユーザーロールまたはユーザータイプに Express Configuration を実行する権限があるかを記載する必要があります。 すでにアプリケーションで Auth0 Organizations を使用していて、[SaaStart リファレンスアプリケーション](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/)に示されているような Organization 管理者ロールを実装している場合は、そのロールに Express Configuration の権限を追加できます。 まだお客様向けに Auth0 Organizations を導入していない場合や、アプリケーションで管理者ユーザーを実装していない場合は、例として示しているカスタマーオンボーディングフローを参照してください。
### 顧客イネーブルメントフローの例
顧客オンボーディングプロセスでは、次の情報を収集する必要があります。 * 顧客の組織名 * Express Configuration を実行する権限を持つべき顧客管理者のメールアドレス * 管理者のドメインを含む、ユーザーに対して顧客の IdP（アイデンティティプロバイダー）が発行する検証済みメールドメイン この情報は、手動で収集するか、顧客向けのサインアップまたはオンボーディングエクスペリエンスを通じて収集します。この情報を使用して、この顧客向けの Auth0 Organization と管理者ユーザーアカウントを作成します。 1. Auth0 Organization を作成します。 2. データベースやメールパスワードレスなどの Auth0 の Connection に管理者ユーザーアカウントを作成します。 3. Connection を Auth0 Organization に関連付けます。**Membership On Authentication** を無効にします。 4. 管理者ユーザーアカウントを Auth0 Organization のメンバーとして追加します。 5. Express Configuration を実行する権限を持つ組織ロールを管理者ユーザーに割り当てます。
#### Auth0 CLI の例
**Auth0 CLI を初期化して認証する** [Auth0 CLI](https://auth0.github.io/auth0-cli/auth0_roles_create.html) を使用して Auth0 に対して認証を行います。 ```bash theme={null} auth0 login --scopes "create:users,create:organizations,create:organization_members,create:organization_member_roles,create:organization_connections" ``` **Auth0 組織を作成する** 組織の名前と、スペースを含まない短い名前を入力します。複数のメールサフィックスを収集している場合は、それらを組織のメタデータとして追加します。 ```bash theme={null} auth0 orgs create --json \ --display "organization_display_name" \ --name "organization_short_name" \ --metadata 'domains=["domain1.com", "domain2.com"]' ``` 返された `org_id` を取得しておきます。 **組織管理者アカウントを作成する** この例では、メールパスワードレス接続でユーザーを作成します。そのためには、[`email`](/docs/ja-JP/authenticate/passwordless/authentication-methods/email-otp) 接続タイプが必要です。このコマンドでは、Express Configuration の実行を許可するユーザーのメールアドレスを入力する必要があります。 ```bash theme={null} auth0 api users \ --data '{"email":"user@example.com","connection":"email", "email_verified":true}' ``` この Organization（組織）を Okta OIN オペレーションチーム向けのユーザー名とパスワードのテストアカウントを提供するために作成している場合は、共有または専用のデータベース接続のいずれかでテストアカウントを作成してください： ```bash theme={null} auth0 api users \ --data '{"email":"user@example.com","connection":"db_connection_name_here", "password": "add_a_long_password_here"}' ``` 返された `user_id` を控えておきます。 **接続を Organization（組織）に関連付ける** 接続 ID を取得します： ```bash theme={null} auth0 api get "connections" -q "name=connection_name_here" ``` 接続 ID を組織 ID（`org_id`）に関連付けます。 ```bash theme={null} auth0 api post "organizations/org_id_here/enabled_connections" \ --data '{ "connection_id": "connection_id_here" }; ``` **管理者ユーザーを組織のメンバーとして追加する** `org_id` と `user_id` が必要です。 ```bash theme={null} auth0 api post "organizations/org_id_here/members" \ --data '{ "members": ["user_id__here"] }' ``` **Express Configuration 権限を持つ組織のロールを割り当てる** [Assign express configuration permissions to users](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#assign-permissions-to-users) で設定した Express Configuration 権限を持つロールの ID を取得します。 ```bash theme={null} auth0 api get "roles" -q "name_filter=role_name_here" ``` ロール ID を `user_id` と `org_id` に割り当てます。 ```bash theme={null} auth0 api post "organizations/org_id_here/members/user_id_here/roles" --data '{ "roles": ["role_id_here"] }' ``` 完了すると、顧客は組織管理者アカウントを使用して、自分たちの Okta 組織内で [OIN インテグレーション](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#publish-your-integration-to-the-oin) を用いた Express Configuration を実行できます。
### 管理者アカウントをプロビジョニングする際の推奨事項
既存のユーザーアカウントを使用する場合でも、Express Configuration を有効化するために新しいアカウントをプロビジョニングする場合でも、以下の推奨事項に従ってください。
#### 仕事用メールを使用する
フェデレーションされていない管理者アカウントがデータベース、パスワードレスのメール、またはソーシャルのユーザーアカウントのいずれであっても、`email` 属性の値は、Okta Enterprise のユーザーアカウントとしてプロビジョニングされる、そのユーザーの勤務先メールアドレスと一致させるのが望ましいです（例: `john@mycompany.com`）。 Auth0 では、[メール検証フロー](/docs/ja-JP/manage-users/user-accounts/verify-emails) を使用して、これらのメールアドレスを検証することを推奨しています。
#### MFA（多要素認証）を使用する
各ログイン時に MFA（多要素認証）を必須にすることで、Express Configuration フローに追加のセキュリティ層を設けることができます。 [Post-Login Action](/docs/ja-JP/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) の例では、Express Configuration が実行されるたびに、[デバイスの生体認証を使用した WebAuthN](/docs/ja-JP/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa) や [メールで送信されるワンタイムパスワード](/docs/ja-JP/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-email-notifications-for-mfa) などの要素による認証を条件付きで要求する方法を示しています。 この Action の例を利用するには、Auth0 テナントであらかじめ[これらの要素を有効化](/docs/ja-JP/secure/multi-factor-authentication/enable-mfa#enable-mfa-in-the-auth0-dashboard)し、**Customize MFA Factors using Actions** オプションを選択しておく必要があります。 ```javascript theme={null} exports.onExecutePostLogin = async (event, api) => { if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") { api.multifactor.enable('any'); api.authentication.challengeWith({ type: 'email' }); if (!event.user.enrolledFactors.some(m => m.type === 'webauthn-platform')) { api.authentication.enrollWith({type: 'webauthn-platform'}); } else { api.authentication.challengeWith({type: 'webauthn-platform'}); } } } ```
### Express Configuration の使用状況を監視する
Express Configuration の使用状況は、設定した各アプリケーションの **OIN Client ID** でフィルタリングすることで、[Auth0 テナント ログ](/docs/ja-JP/deploy-monitor/logs) から確認できます。これには、すべての管理者ユーザーのログインアクティビティに加えて、Okta Enterprise 接続を作成および管理するためのすべての API 操作が含まれます。 アプリケーションの OIN Client ID は次の場所で確認できます。 * Auth0 Dashboard の **Applications > \[Application] > Okta Integration Network > Request Integration > Request Express Configuration** セクション。 * [Auth0 Management API](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id) でアプリケーションを表示したときの `express_configuration.okta_oin_client_id` プロパティ。 To learn more on searching logs with Client ID, read [Log Search Query Syntax](/docs/ja-JP/deploy-monitor/logs/log-search-query-syntax).
## 制限事項
* 1 つの OIN 統合で使用できる Auth0 テナントは 1 つのみです。同じアプリケーションを複数の Auth0 リージョンにデプロイする場合、各リージョンごとに独自の OIN 統合が必要です。 * 1 つの Okta 組織内の 1 つの OIN 統合につき、対応する 1 つの Auth0 組織内に 1 つの一意の Okta 接続のみを作成できます。1 つの Okta 組織内で複数の OIN アプリケーション インスタンスに対して Express 構成を使用することはできません。 * OIN に一覧表示されている一意の統合ごとに、独立した Okta 接続が作成されます。ホーム レルム検出を伴う [Identifier-First ログイン エクスペリエンス](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first) を必要とするアプリケーションが複数ある場合は、[単一の統合の下に複数のアプリケーションを公開する](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration)ことを推奨します。 * [単一の統合の下に複数のアプリケーションを有効にする](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration)場合、Okta は [エンド ユーザー ダッシュボード](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm) にメイン OIN アプリケーションのみを表示します。
## Management API reference
特定のアプリケーションで Express Configuration を有効にする際に Auth0 Dashboard の代わりに [Management API](https://auth0.com/docs/api/management/v2) を使用する場合は、以下の例を参照してください。
### Okta OIN Express Configuration System API を作成する
組織管理者を認証するために使用されるリソースサーバーを登録します。これは、テナント内のアプリに対する Express Configuration のセットアップにダッシュボードを一度も使用していない場合にのみ必要になります。 例： ```curl theme={null} POST /api/v2/resource-servers { "name": "Okta OIN Express Configuration API", "identifier": "urn:auth0:express-configure" } ``` [エンドポイントリファレンス](/docs/ja-JP/api/management/v2/resource-servers/post-resource-servers)
### ユーザー属性プロファイルの作成
[ユーザー属性プロファイル](/docs/ja-JP/authenticate/enterprise-connections/user-attribute-profile)を作成します。この手順が必要になるのは、既存のプロファイルが存在しない場合、または開発者がカスタムプロファイルを使用したい場合だけです。 ユーザー属性プロファイル用のデフォルト設定から開始するには、まず `GET /api/v2/user-attribute-profiles/templates` エンドポイントを呼び出し、そのレスポンスボディをユーザー属性プロファイル作成呼び出しのリクエストボディとして使用します。 例: ```curl theme={null} GET /api/v2/user-attribute-profiles/templates ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/user-attribute-profiles/post-user-attribute-profiles) ```curl theme={null} POST /api/v2/user-attribute-profiles { "name": "Okta OIN Express Configuration API", "identifier": "urn:auth0:express-configure" } ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/user-attribute-profiles/post-user-attribute-profiles)
### Connection プロファイルを作成する
Connection プロファイルを作成します。この手順が必要になるのは、既存のプロファイルがない場合、または開発者がカスタムプロファイルを使用したい場合のみです。 Connection プロファイルのデフォルト設定をベースにするには、`GET /api/v2/connection-profiles/templates` エンドポイントを呼び出し、そのレスポンスを使用して Connection プロファイルを作成するリクエストボディを構成します。 例: ```curl theme={null} GET /api/v2/connection-profiles/templates ``` [エンドポイントリファレンス](https://auth0.com/docs/api/management/v2/connection-profiles/get-connection-profile-templates) ```curl theme={null} POST /api/v2/connection-profile { "name": "Okta OIN Express Configuration API", "identifier": "urn:auth0:express-configure" } ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/connection-profiles/post-connection-profiles)
### OIN Express Configuration クライアントを作成する
特定のアプリケーション向けに、Express Configuration 中に Okta が使用するサービスアプリケーションを作成します。このクライアントは、以下の例に示すプロパティを使用して作成する必要があります。 `organization_require_behavior` 属性は、以下のいずれかの値でカスタマイズできます。各値の説明については、[管理者のログインと同意の設定](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#administrator-login-and-consent-settings)を参照してください。 * `pre_login_prompt`: 資格情報の入力を促す前に、管理者の所属組織を確認するプロンプトを表示します。 * `post_login_prompt`: 管理者の資格情報の入力を促すプロンプトを表示します。このオプションを使用する場合は、`PATCH /api/v2/connections/{id}` エンドポイントを使用して、管理者アカウントを含む接続の `enabled_clients` プロパティに OIN クライアントのクライアントID を追加します。 例： ```curl theme={null} POST /api/v2/clients { "name": "Okta OIN Express Configuration", "app_type": "express_configuration", "organization_require_behavior": "pre_login_prompt", "client_authentication_methods": { "private_key_jwt": { "credentials": [] } } } ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/clients/post-clients)
### SaaS アプリケーションのプロパティを構成する
OIN に公開される登録済みアプリケーションの `express_configuration` プロパティに対して、構成値を設定します。例中の値は、この連携で使用する有効な Connection プロファイル ID、User Attribute プロファイル ID、OIN クライアントアプリケーション ID、ログイン開始 URI、および Auth0 テナントドメインに置き換えてください。 `linked_clients` 属性は、[単一の連携で複数のアプリケーションを有効化する](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration) で説明されている設定に対応します。 `enable_client` 属性は、[組織のログイン設定](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#organization-login-settings) で説明されている `enabled_clients` の設定に対応します。 `enable_organization` 属性は、作成した接続を組織に割り当てない場合を除き、通常は `true` に設定してください。Okta アプリインスタンスは引き続き接続を管理できますが、Okta ユーザーは Auth0 組織のメンバーにはなりません。[接続間で管理者アカウントの対応付けを維持する](/docs/ja-JP/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#maintain-admin-account-matching-across-connections) で説明されているケースでは、これを `false` に設定すると便利な場合があります。 例: ```curl theme={null} PATCH /api/v2/clients/{id} { "express_configuration": { "admin_login_domain": "yourAuth0TenantDomain", "connection_profile_id": "yourConnectionProfileId", "enable_client": true, "enable_organization": true, "initiate_login_uri_template": "yourInitiateLoginUriTemplate", "okta_oin_client_id": "yourOinClientId", "user_attribute_profile_id": "yourConnectionProfileId", "linked_clients": [ { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" } ] } } ``` [エンドポイントリファレンス](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id)
### 公開鍵をアップロードする
Okta チームから提供された公開鍵を、OIN クライアント アプリケーションの認証情報としてアップロードします。 例: ```curl theme={null} POST /api/v2/clients/{oin_client_id}/credentials { "credential_type": "public_key", "pem": "-----BEGIN PUBLIC KEY-----\nMIGf..." } ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/clients/post-credentials)
### OIN クライアントアプリケーションにキーを割り当てる
Okta にアップロードした公開鍵を OIN サービスクライアントに割り当てます。`yourCredentialId` を、前の手順で取得したクレデンシャル ID に置き換えます。 例: ```curl theme={null} PATCH /api/v2/clients/{oin_client_id} { "client_authentication_methods": { "private_key_jwt": { "credentials": [ { "id": "yourCredentialId", } ] } } } ``` [エンドポイントリファレンス](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id) テナント設定を更新して、同意ページにスコープの詳細を表示するようにします。これらの設定により、付与される権限に関する情報を提供できるため、ユーザーエクスペリエンスが向上します。必須ではありませんが、設定することを推奨します。 例: ```curl theme={null} PATCH /api/v2/tenants/settings { "flags": { "use_scope_descriptions_for_consent": true } } ``` [エンドポイント リファレンス](https://auth0.com/docs/api/management/v2/tenants/patch-settings)