> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Auth0 Dashboard で利用できる、アプリケーション関連の設定について説明します。
# アプリケーション設定
Dashboard の [Applications](https://manage.auth0.com/#/applications) ページで一覧からアプリケーションを見つけ、その名前をクリックすると、利用可能な設定を表示できます。
[サードパーティアプリケーション](/ja/docs/get-started/applications/third-party-applications) では、設定できるプロパティが制限されています。サポート対象に含まれないプロパティは、Auth0 Dashboard または Management API では設定できません。詳しくは、[Security Controls for Third-Party Applications](/ja/docs/get-started/applications/third-party-applications/security-controls#restricted-client-configuration) を参照してください。
## 基本設定
既存のアプリケーションの設定を編集する場合も、新しいアプリケーションを作成する場合も、**Settings** ビューでアプリケーションの情報を入力します。
### 基本情報
* **名前**: アプリケーションの名前です。編集可能で、ポータル、メール、ログなどに表示されます。
* **ドメイン**: Auth0テナント名です。これは新しいAuth0テナントの作成時に選択するもので、後から変更することはできません。別のドメインが必要な場合は、右上のメニューで **+ Create Tenant** を選択して、新しいテナントを登録する必要があります。
* **クライアントID**: アプリケーションの一意の識別子です。Auth0で認証を設定する際に使用します。新しいアプリケーションの作成時にシステムによって生成され、変更することはできません。
* **クライアントシークレット**: 認証フローで IDトークン の署名と検証を行い、一部のAuth0 APIエンドポイントへのアクセスを取得するために使用される文字列です。デフォルトでは値は非表示になっているため、表示するには **Reveal Client Secret** ボックスをオンにします。クライアントIDは公開情報と見なされますが、クライアントシークレットは **必ず機密情報として保持する必要があります**。クライアントシークレットに第三者がアクセスできると、その相手がトークンを発行し、本来アクセス権のないリソースにアクセスできてしまいます。
* **説明**: アプリケーションの目的を記述する自由入力のテキストです。最大140文字です。
### アプリケーションのプロパティ
* **Application Logo**: アプリケーションに表示するロゴの URL です (推奨サイズ: 150 x 150 ピクセル) 。Dashboard のアプリケーション一覧や、カスタマイズされた同意画面など、複数の場所に表示されます。設定されていない場合は、この種類のアプリケーションのデフォルトバッジが表示されます。
* **Application Ownership**: アプリケーションがファーストパーティかサードパーティアプリケーションかを示します。サードパーティアプリケーションには、[強化されたセキュリティ制御](/ja/docs/get-started/applications/third-party-applications/security-controls) が適用されます。アプリケーションの所有区分は作成時に設定され、あとから変更することはできません。詳しくは、[First-Party and Third-Party Applications](/ja/docs/get-started/applications/first-party-and-third-party-applications) を参照してください。
* **Application Type**: Auth0 アプリケーションのタイプによって、Dashboard で設定できる項目が決まります。 (M2M アプリでは編集できません。また、選択したグラントタイプが現在選択中のアプリケーションタイプでのみ許可されている場合は、他の Auth0 アプリケーションタイプでも無効になることがあります。) ドロップダウンから、次のタイプを選択します。
* [Machine to Machine](/ja/docs/get-started/auth0-overview/create-applications/machine-to-machine-apps): コマンドラインツール、デーモン、IoT デバイス、バックエンドで実行されるサービスなどの非対話型アプリケーションです。通常、API へのアクセスが必要なサービスがある場合は、このオプションを使用します。
* [Native App](/ja/docs/get-started/auth0-overview/create-applications/native-apps): デバイス上でネイティブに実行されるモバイルアプリケーションまたはデスクトップアプリケーションです (iOS や Android など) 。
* [Regular Web App](/ja/docs/get-started/auth0-overview/create-applications/regular-web-apps): アプリケーションロジックの大部分をサーバー上で実行する従来型の Web アプリケーションです (Express.js や ASP.NET など) 。
* [Single Page App](/ja/docs/get-started/auth0-overview/create-applications/single-page-web-apps): ユーザーインターフェースロジックの大部分を Web ブラウザー内で実行し、主に API を使用して Web サーバーと通信する JavaScript アプリケーションです (AngularJS + Node.js や React など) 。
### アプリケーションのURI
* **Application Login URI**: 一部のシナリオでは、Auth0 がアプリケーションをそのログインページにリダイレクトする必要があります。この URI は、テナントの `/authorize` [エンドポイント](https://auth0.com/docs/api/authentication#authorize-application) にリダイレクトする、アプリケーション内のルートを指している必要があります。通常は `https://myapp.org/login` の形式です。このフィールドでは、次のプレースホルダーを使用できます。
* [**Organization metadata placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#organization-url-placeholders): `{organization.metadata.KEY}` を使用すると、リクエストに関連付けられた Auth0 組織のメタデータに基づいて URL を動的に設定できます (例: `https://{organization.metadata.public_login_host}/login`) 。
* [**カスタムドメイン placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#custom-domain-url-placeholders): `{custom_domain.metadata.KEY}` を使用すると、リクエストで使用されたカスタムドメインのメタデータに基づいて URL を動的に設定できます (例: `https://{custom_domain.metadata.public_app_host}/login`) 。
詳細については、[Configure Default Login Routes](/ja/docs/authenticate/login/auth0-universal-login/configure-default-login-routes#dynamic-login-uris-with-metadata-placeholders) を参照してください。
* **Allowed Callback URLs**: ユーザーの認証後に Auth0 がリダイレクトできる URL のセットです。有効な URL は複数指定でき、カンマ区切りで入力します (通常は QA やテストなど、異なる環境に対応するためです) 。本番環境では、URL が localhost を指していないことを確認してください。このフィールドでは、次のプレースホルダーを使用できます。
* [**Wildcards**](/ja/docs/get-started/applications/wildcards-for-subdomains#wildcard-url-placeholders): サブドメインには `*` を使用します (`*.google.com`) *本番環境では推奨されません。*
* [**Organization placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#organization-url-placeholders): `{organization_name}` を使用すると、登録済みの組織名を動的に指定できます (例: `https://{organization_name}.example.com`) 。
* [**カスタムドメイン placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#custom-domain-url-placeholders): `{custom.domain.metadata.KEY}` を使用すると、リクエストで使用されたカスタムドメインのメタデータに基づいて URL を動的に設定できます (例: `https://{custom_domain.metadata.public_app_url}/callback`) 。
このフィールドで最初に指定された URL は、対応するプロトコルフローでコールバック URL が明示的に指定されていない場合、デフォルトのコールバック URL として使用されます。これは特に、SAML、WS-Fed、および SAML IdP 起点の SSO フローに適用されます。
アプリケーションのコールバックや許可されたオリジンのフィールドでは、ワイルドカードプレースホルダーや localhost URL を使用しないでください。ワイルドカードプレースホルダーを含むリダイレクト URL を使用すると、アプリケーションが攻撃を受けやすくなる可能性があります。詳細については、[owasp.org の Unvalidated Redirects and Forwards Cheat Sheet](https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet) を参照してください。代わりに、該当する場合は `{organization_name}` プレースホルダーを含む URL を優先してください。詳細については、[Subdomain URL Placeholders](/ja/docs/get-started/applications/wildcards-for-subdomains) を参照してください。
* **Allowed Logout URLs**: ユーザーが Auth0 からログアウトした後、`returnTo` クエリパラメーターを使ってリダイレクトできます。`returnTo` で使用する URL は、ここに含まれている必要があります。有効な URL はカンマ区切りで複数指定できます。本番環境では、URL が localhost を指していないことを確認してください。
* [**Wildcards**](/ja/docs/get-started/applications/wildcards-for-subdomains#wildcard-url-placeholders): サブドメインには `*` を使用します (`*.google.com`) 。*本番環境では推奨されません。*
* [**カスタムドメイン placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#custom-domain-url-placeholders): `{custom.domain.metadata.KEY}` を使用すると、リクエストで使われたカスタムドメインのメタデータに基づいて URL を動的に設定できます (例: `https://{custom_domain.metadata.public_app_url}/callback`) 。
* **Allowed Web Origins**: [Cross-Origin Authentication](/ja/docs/authenticate/login/cross-origin-authentication)、[Device Flow](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)、およびレスポンスモードとして `web_message` を使用する認可リクエストの送信元にできる URL の一覧です。有効な URL はカンマ区切りで複数指定できます。本番環境では、URL が localhost を指していないことを確認してください。これらの URL の検証では、パス、クエリ文字列、ハッシュ情報は考慮されません (実際には、これらが原因で一致に失敗する場合があります) 。**Allowed Web Origins** フィールドには最大 100 個の URL を指定できます。
* [**Wildcards**](/ja/docs/get-started/applications/wildcards-for-subdomains#wildcard-url-placeholders): サブドメインには `*` を使用します (`*.google.com`) 。*本番環境では推奨されません。*
* [**カスタムドメイン placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#custom-domain-url-placeholders): `{custom.domain.metadata.KEY` を使用すると、リクエストで使われたカスタムドメインのメタデータに基づいて URL を動的に設定できます (例: `https://{custom_domain.metadata.public_app_url}/callback`) 。
* **Allowed Origins (CORS)**: Auth0 に対して Cross-Origin Resource Sharing (CORS) リクエストを実行できる URL の一覧です。
* [**カスタムドメイン placeholders**](/ja/docs/get-started/applications/wildcards-for-subdomains#custom-domain-url-placeholders): `{custom.domain.metadata.KEY}` を使用すると、リクエストで使われたカスタムドメインのメタデータに基づいて URL を動的に設定できます (例: `https://{custom_domain.metadata.public_app_url}/callback`) 。
Application URL を カスタムドメイン placeholders のみで設定した場合、テナントの正規ドメイン (例: [https://your-tenant.us.auth0.com](https://your-tenant.us.auth0.com)) 経由で行われる認証リクエストは失敗します。
これは、正規ドメインにはプレースホルダーの解決に必要なカスタムメタデータがないためです。認証には対象のカスタムドメインを使用するようにするか、正規ドメインの使用が必要な場合は静的なフォールバック URL を指定してください。
### IDトークン
**IDトークン** セクションで、Auth0 の `id_token` が期限切れになるまでの時間である **IDトークンの有効期限** (秒) を入力します。デフォルト値は 36000 秒 (10 時間) です。
**シングルサインオンには IdP ではなく Auth0 を使用**: 有効にすると、Auth0 は、有効なセッションを持つ認証済みユーザーを IDプロバイダー (Facebook や ADFS など) にリダイレクトしないようにします。**レガシーテナントのみ。**
### リフレッシュトークンローテーション
**リフレッシュトークン ローテーション** セクションで、ローテーションを有効または無効にします。有効にすると、リフレッシュトークンを交換した際に新しいリフレッシュトークンが発行され、既存のトークンは無効化されます。これにより、トークンが漏えいした場合に、トークンの再利用を自動的に検出できます。さらに、**Rotation Overlap Period** (秒単位) を入力します。この期間は、自動的な再利用検出を発生させることなく、同じ `refresh_token` を使って `access_token` をリクエストできる許容猶予時間です。詳細については、[リフレッシュトークンローテーション](/ja/docs/secure/tokens/refresh-tokens/refresh-token-rotation) を参照してください。
### リフレッシュトークンの有効期限
**リフレッシュトークンの有効期限** セクションで、絶対有効期限と非アクティブ時の有効期限の有効/無効を切り替え、それぞれの有効期間 (秒) を設定します。詳細については、[リフレッシュトークンの有効期限を設定する](/ja/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration)を参照してください。
### オープンリダイレクト保護
サードパーティアプリケーションに対するリダイレクトを Auth0 がどのように処理するかを制御します。この設定は、強化されたセキュリティ制御が適用されたサードパーティアプリケーションでのみ使用できます。
有効にすると (サードパーティアプリのデフォルト) 、認証エラー時に Auth0 はアプリケーションのコールバック URL にリダイレクトせず、メールテンプレートで `application.callback_domain` も公開しません。これにより、リダイレクト URI が信頼できない第三者によって制御されている場合のオープンリダイレクト攻撃を防止できます。
設定済みのコールバック URI を信頼できるサードパーティアプリケーションでのみ、オープンリダイレクト保護を無効にしてください。
詳細については、[リダイレクト保護](/ja/docs/get-started/applications/third-party-applications/security-controls#redirect-protection)を参照してください。
## 詳細設定
**詳細設定** セクションでは、次のことができます。
* アプリケーションのメタデータ、デバイス、OAuth、および WS-Federation の設定を管理または追加する
* 証明書や トークンエンドポイント に関する情報を取得する
* アプリケーションのグラントタイプを設定する
### アプリケーションのメタデータ
アプリケーションのメタデータは、アプリケーションごとに設定するカスタム文字列のキーと値です (各キーと値の最大文字数は 255 文字) 。メタデータは、アプリケーションオブジェクトでは `client_metadata`、Rules では `context.clientMetadata` として公開されます。作成できるメタデータセットは最大 10 個です。
### デバイス設定
モバイルアプリを開発する場合は、必要な iOS/Android パラメーターを入力します。
* iOS アプリを開発する場合は、**Team ID** と **App ID** を入力します。詳細は、[Apple Xcode で Universal Links サポートを有効にする](/ja/docs/get-started/applications/enable-universal-links-support-in-apple-xcode)を参照してください。
* Android アプリを開発する場合は、**App Package Name** と **Key Hashes** を入力します。詳細は、[Android App Links サポートを有効にする](/ja/docs/get-started/applications/enable-android-app-links-support)を参照してください。
### OAuth
* デフォルトでは、すべてのアプリ/API がデリゲーションリクエストを実行できます。特定のアプリ/API に明示的に権限を付与する場合は、**Allowed Apps/APIs** で設定します。
* Highly Regulated Identity add-on を使用している場合は、**Compliance Enforcement Level** 設定を使用してコンプライアンスレベルを設定します。詳しくは、[FAPI コンプライアンスを設定する](/ja/docs/get-started/applications/configure-fapi-compliance)を参照してください。
* **Non-Verifiable Callback URI End-User Confirmation**: コールバックに Non-verifiable URI が使用される場合に、ログイン確認をユーザーに求めるかどうかをこの設定で制御します。Auth0 では、このような場合にエンドユーザー確認をスキップしないことを推奨しています。この設定は、同名のテナント設定よりも優先されます。詳しくは、[アプリケーションのなりすまし対策](/ja/docs/secure/security-guidance/measures-against-app-impersonation.mdx)を参照してください。
* JSON web tokens の署名に使用するアルゴリズム ([**HS256**](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) または [**RS256**](https://en.wikipedia.org/wiki/Public-key_cryptography)) を設定します。詳しくは、[JSON Web Token の署名アルゴリズム](/ja/docs/get-started/applications/signing-algorithms)を参照してください。`RS256` (推奨) を選択すると、トークンはテナントの秘密鍵で署名されます。
* **Trust Token Endpoint IP Header** 設定を切り替えます。これを有効にすると、`auth0-forwarded-for` が信頼できるものとして扱われ、トークンエンドポイント でのブルートフォース攻撃対策のためのエンドユーザー IP 情報のソースとして使用されます。この設定は、Regular Web Apps と M2M Apps でのみ使用できます。
* スイッチを切り替えて、アプリケーションが **OIDC 準拠** かどうかを指定します。OIDC 準拠としてフラグ付けされたアプリケーションは、OIDC 仕様に厳密に従います。
### グラントタイプ
アプリケーションで有効または無効にするグラントタイプを選択します。利用可能なグラントタイプは、アプリケーションの種類と[アプリケーションの所有形態](/ja/docs/get-started/applications/first-party-and-third-party-applications)に応じて異なります。セキュリティ制御が強化されたサードパーティアプリケーションでは、`authorization_code`、`refresh_token`、`client_credentials` がサポートされます。
### WS-Federation
WS-Federation 設定を管理または追加します。
### 証明書
署名証明書と、そのフィンガープリントおよびサムプリントを管理または追加します。
### エンドポイント
認可 URL やメタデータ URL など、OAuth、SAML、WS-Fed のエンドポイント情報を確認できます。
## 詳細
* [アプリケーションを作成する](/ja/docs/get-started/auth0-overview/create-applications)
* [アプリケーションを削除する](/ja/docs/get-started/applications/remove-applications)
* [OIDC ディスカバリーを使用してアプリケーションを設定する](/ja/docs/get-started/applications/configure-applications-with-oidc-discovery)
* [コンフィデンシャルアプリケーションとパブリックアプリケーション](/ja/docs/get-started/applications/confidential-and-public-applications)
* [ファーストパーティアプリケーションとサードパーティアプリケーション](/ja/docs/get-started/applications/first-party-and-third-party-applications)